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Executive  SuBonarv 


The  overall  objective  of  the  Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  Program  is  to  integrate 
the  design,  manufacturing,  and  logistic  functions  through  the 
efficient  application  of  computer  technology.  CALS  is  a  program 
to  apply  existing  and  emerging  communications  and  computer-aided 
technologies  in  DoD  and  industry  to: 

o  Integrate  and  improve  design,  manufacturing,  and  logistic 
functions;  thereby  bridging  existing  "islands  of 
automation. " 

o  Actively  influence  the  design  process  to  produce  weapon 
systems  that  are  more  reliable  and  easier  to  support  and 
maintain. 

o  Shift  from  current  paper- intensive  weapon  support 
processes  to  a  highly  automated  mode  of  operation,  based 
on  a  unified  DoD  interface  with  industry  for  exchange  of 
logistic  technical  information  in  digital  form. 

The  CALS  program  was  established  by  the  Deputy  Secretary  of  Defense 
in  September  1985  to  implement  the  recommendations  of  a  Joint 
Industry/DoD  Task  Force.  Management  is  provided  by  a  DoD  steering 
Group,  the  OSO  CALS  Office,  and  a  lead  organization  in  each 
Military  Department  and  the  Defense  Logistics  Agency.  The  DoD  CALS 
Office  has  obtained  the  support  of  the  National  Institute  of 
Standards  and  Technology  in  the  selection  and  implementation  of 
CALS  standards.  An  Industry  Steering  Group  has  also  been 
established  to  focus  the  work  of  key  industrial  associations  and 
the  defense  contractor  community  in  CALS  implementation. 

The  CALS  strategy  provides  a  plan  for  phased  implementation  of 
CALS.  Phase  I  will  apply  current  computer  technology  in 
existing/emerging  DoD  and  industry  systems  for  key  logistic  and 
design  applications.  Phase  II  will  involve  broad-based  DoD  and 
industry  system  redesign  to  implement  advanced  technology  across 
a  wider  range  of  applications  during  the  early  1990 's.  DoD  is 
currently  developing  core  Phase  I  requirements.  Demonstrations 
and  prototypes  will  support  Phase  I  implementation,  while  advanced 
technology  R&D  continues  for  Phase  II. 
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Implementation  of  the  CALS  program  will  result  in: 

o  Design  of  more  supportable  weapon  systems, 

o  Increased  productivity  and  reduced  cost  of  weapon  system 

acquisition  and  logistic  support, 
o  Improved  timeliness  and  accuracy  of  logistic  technical 
information . 

o  Enhanced  operational  readiness  of  military  forces. 

During  FY86  NIST  recommended  standards  to  OSD  which  would  be 
applicable  to  the  DoD  environment.^  These  recommendations  included 
CALS  use  of  standards  in  the  areas  of  product  definition, 
graphics,  text,  and  data  management. 

CALS  support  work  in  FY87  focussed  on  the  following  activities: 
Developing  a  CALS  framework.  Development  Plan  and  Core  Requirements 
package;  providing  technical  support  for  standards  development  and 
implementation;  and  conducting  workshops  and  meetings  to  promote 
dialogue  with  the  Services,  the  Defense  Logistic  Agency,  and 
industry.  A  major  thrust  was  the  completion  of  the  initial 
documentation  of  the  high-priority  standards  required  for  CALS 
implementation . ^ 

During  FY88,  a  number  of  efforts  advanced  the  development  of 
technology  and  standards  in  support  of  CALS.  These  efforts  were 
organized  into  the  areas  of  Text,  Graphics,  and  Product  Data. 

Text:  Work  on  text  and  graphics  standards  in  the  CALS  publishing 
environment  included  technology  assessments,  development  of 
application  guidance,  conformance  test  plans  and  a  draft  FIPS  for 
ODA/ODIF.  Additionally,  a  technology  assessment  and  proposed 
conformance  testing  strategy  were  developed  for  page  description 
languages. 

Graphics:  The  CALS  efforts  in  CGM  were  continued  and  included  work 
in  the  graphics  standards  committees  and  the  expansion  and  updating 
of  the  CALS  CGM  Application  Profile.  The  Application  Profile  was 
developed  into  a  draft  military  specification.  The  draft  was 
carried  through  the  needed  review  and  comment  process  and  was 
published  as  MIL-D-28003  in  December  1988.  In  addition,  work  on 
Extended  CGM,  or  CGEM  for  CALS  application  was  initiated.  Work  in 


^Kemroerer,  S.,  Editor,  "Final  NBS  Report  for  CALS,  FY86,"  U.S. 
Department  of  Commerce,  National  Bureau  of  Standards,  NBSIR  87- 
3566,  May  1987. 

^Kemmerer,  S.  Editor,  "A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1987,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-3726,  NBSIR  88-3727,  NBSIR 
88-3728,  and  NBSIR  88-3729,  March  1988. 
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the  area  of  raster  graphics  continued.  A  draft  MILSPEC  for  raster 
was  developed  which  was  later  published  as  MIL>R-28002.  The  need 
for  standards  for  the  interchange  of  large  format  tiled  raster 
documents  was  identified,  and  related  technical  papers  were 
published  separately  as  an  NIST  Internal  Report.’ 

Product  Data:  The  use  of  the  Information  Resource  Dictionary 
System,  (IRDS,  ANSI  Standard  X3. 138-1988)  was  proposed  as  an 
integration  and  configuration  management  mechanism  for  the  Product 
Data  Exchange  Specification  (PDES) . 


’spielman,  F. ,  Editor,  "Standards  for  the  Interchange  of  Large 
Format  Tiled  Raster  Documents,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-4017,  December  1988. 
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These  three  volunes  are  a  collection  of  the  final  reports  presented 
to  the  DoD  CALS  Office/  The  collection  is  divided  as  follows: 


VOUJME  1. 

Text,  Security,  and  Data  Management 

Text  and  Graphics  Standards  in  the  CALS  Publishing  Environment 
ODA/ODIF  Application  Guidance 

Federal  Information  Processing  Standards  Publication  (Draft) 
on  Document  Application  Profile  for  the  Office  Document 
Architecture  (ODA)  and  Interchange  Format  Standard 

ODA/ODIF  Conformance  Test  Plan 

PDLs:  A  Technology  Assessment 

SPDL  Conformance  Strategy 

Security 

Risk  Management  Tools:  A  Guide  to  Selection  and  Use 

Computer  Security  Issues  in  the  Application  of  New  and 
Emerging  Information  Technologies 

Data  Management 

Information  Resource  Dictionary  System:  An  Integration 
Mechanism  for  Product  Data  Exchange  Specification 

Using  the  Information  Resource  Dictionary  System  for  PDES 

VOLUME  2: 

Graphics,  CGM  MIL-SPEC 

CGM  Conformance  Testing 
Final  Phase  I.l  CGM  MLSPEC 
Extended  CGM  MILSPEC  Planning 


‘The  publishing  of  this  collection  of  reports  does  not  imply 
that  the  CALS  Office  has  endorsed  the  conclusions  or  recommenda¬ 
tions  presented. 
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Graphics,  CGM  Registration 

CGM  Registration  in  Support  of  CALS 


The  following  additional  publications  were  completed  by  NIST  during 
FY87  under  separate  cover.  They  are  available  through  NTIS. 


CALS  Workshop  Proceedings:  CALS  EXPO  *88  'Quality  and  Producti¬ 
vity  Through  Integration”  A  DoD/Industry  NIST 
Conference  4-6  October  1988 

MIL-HDBK-59,  Military  Handbook:  Department  of  Defense  Computer- 
aided  Acquisition  and  Logistic  Support  (CALS) 
Program  Implementation  Guide 

MIL-STD-1840A,  Automated  Interchange  of  Technical  Information 

MIL-D-28000,  Military  Specification:  Digital  Representation  for 
Communication  of  Product  Data:  IGES  Application 
Subsets 

MIL-M-28001,  Military  Specification:  Markup  Requirements  and 
Generic  Style  Specification  for  Electronic  Printed 
Output  and  Exchange  of  Text 

MIL-R-28002,  Military  Specification:  Raster  Graphics 

Representation  in  Binary  Format,  Requirements  for 

MIL-D-28003,  Military  Specification:  Digital  Representation  for 
Communication  of  Illustration  Data:  CGM  Application 
Profile 


vii 


CONTRIBUTIONS 


NIST  would  like  to  acknowledge  the  major  technical  contributors  to 
this  volume.  In  alphabetical  order  they  are: 


Daniel  Benigni 
George  Carson 


viii 


CGM  Registration  in  Support  of  CALS 


CALS  SOW  TASK  3.1.3 


FIHAL  REPORT 


CELS  SOW  TASK  3.1.3 
CGM  REGISTRATION  IN  SUPPORT  OF  CALS 


TABLE  OF  CONTENTS 


I.  PURPOSE .  2 

II.  BACKGROUND . 2 

III.  DISCUSSION .  3 

1.0  Ras'ter  Input  Extensions .  3 

1.1  Introduction . 4 

1.2  Requirements .  4 

1.3  Features  of  Interpress .  6 

1.4  Features  of  TIFF . 7 

2.0  Conclusion  of  Registration  for  Line  Types,  Hatch 

Styles  and  Text  Fonts .  10 

3.0  Follow  Through  on  Previous  Registration  Proposals  11 

3.1  Presentation  of  Section  Lining . .  .  14 

3.2  Presentation  of  Line  Conventions .  15 

IV.  CONCLUSIONS  AND  RECOMMENDATIONS .  17 

1.0  Revised  Registration  Proposals . ,  .  .  17  ^ 

APPENDIX  1  Responses  to  Ballot  Comments . 151 


xii 


C6M  REGISTRATION  IN  SUPPORT  OF  CALS 


I.  PURPOSE 

Define  the  CGM  extensions  needed  to  support  CALS.  Support 
identified  extensions  through  the  registration  process  (CALS  SOW 
Task  3.1.3). 

II.  BACKGROUND 

In  the  previous  fiscal  year  (refer  to  NBSIR  88-3728,  Vol.3)  NIST 
(the  National  Institute  of  Standards  and  Technology,  formerly 
NBS)  presented  a  list  of  extensions  needed  for  the  CGM  to  meet 
CALS  requirements.  These  extensions  were  to  be  implemented 
through  the  Graphics  Registration  Process.  In  addition,  a  number 
of  areas  were  identified  as  requiring  further  investigation, 
including  curves,  text,  raster  images,  named  items  and  symbol 
libraries.  As  a  final  product,  a  significant  number  of 
registration  proposals  were  developed  and  submitted  to  ANSI  for 

formal  processing  through  ISO. 

• 

This  task  was  a  continuation  of  that  work.  It  consisted  of  three 
items : 

1)  Item  One:  Develop  and  define  Raster  Encoded  Extensions  and 
Raster  Data  Types  to  fully  support  technical  and  adiiinistrative 
pxiblications  in  CALS,  and  follow  through  to  ISO  acceptance. 

2)  Item  Two:  Define  registration  requirements  and  develop 
registration  proposals  needed  to  work  in  areas  of  line  types, 
hatch  styles  and  text  fonts,  and  follow  through  to  ISO 
acceptance. 

3)  Item  Three:  Follow  through  to  ISO  acceptance  proposals 
currently  in  the  registration  process  as  a  result  of  last  year's 
work,  negotiating  any  requirement  changes. 

As  a  result  of  work  on  this  task,  computer  graphics  standards 
will,  for  the  first  time,  be  capable  of  supporting  real-world 
applications  in  technical  and  administrative  publications  and 
engineering  documentation.  Once  the  registration  proposals 
developed  under  this  contract  are  processed,  it  will  no  longer  be 
necessary  to  use  IGES  to  exchange  engineering  drawings,  CCITT 
facsimile  standards  to  exchange  raster  data,  or  PostScript  to 
describe  graphics  in  office  documents,  if  so  desired. 
Furthermore,  the  work  done  under  this  task  has  been  adopted  by 
ANSI  and  ISO  as  the  basis  for  extensions  to  the  family  of 
existing  Computer  Graphics  standards.  For  example.  Addendum  3  to 
the  CGM  contains  precisely  the  extensions  that  this  task  has 
defined  as  being  necessary.  This  addendum  copies  material  that 
NIST  wrote  almost  word  for  word  in  most  cases. 


1 


During  this  fiscal  year,  the  ISO/IEC  JTC1/SC24  meeting  was 
attended,  where  the  Registration  proposals  which  were  originated 
last  fiscal  year  were  processed.  The  Special  Working  Group 
meeting  on  the  Font  Architecture  standard  (OIS  9541)  was  also 
attended,  and  contributions  to  the  development  of  a  substantially 
revised  architecture  were  made. 


III.  DISCUSSION 

1.0  Raster  Input  Extensions 

A  set  of  raster  extensions  to  the  CGM  that  equip  it  with 
descriptive  caped)ilities  that  are  either  substantially  equivalent 
to  or  better  than  those  in  CCITT  Group  3/4  facsimile,  PostScript, 
Interpress,  and  TIFF  have  been  developed.  These  extensions  make 
use  of  the  power  already  inherent  in  the  available  specification 
modes  of  the  CGM  and  are  both  considerably  simpler  and  more 
compatible  with  existing  computer  graphics  standards  than  those 
developed  by  the  CGM  group  of  ANSI/ISO  and  described  in  the  draft 
CGM  Addendum  3  (SC24  N  52) .  This  was  accomplished  by: 

1)  Using  the  P  ,Q  ,and  R  parameterization  of  Cell  Array  to 
provide  the  required  pel  path  and  line  progression 
capabj^lities; 

2)  Using  the  available  scaling  mode  of  the  CGM  to  carry  any  pel 
spacing  and  spacing  ratio  data  by  implication  through 
specification  of  metric  mode  with  a  scale  factor  equating 
VOC  units  to  SMUs; 

3)  Using  the  nx  and  ny  parameterization  of  Cell  Array  to 
provide  the  required  number  of  pels  per  line  and  number  of 
lines,  rather  than  inventing  unnecessary  new  concepts; 

4)  Using  existing  CGM  clipping  rectangle  features  to  designate 
sub-areas  of  tile  pel  array,  rather  than  inventing  an 
unnecessary  new  element. 

Further,  these  extensions  go  considerably  beyond  those  of  the 
extended  metafile  work,  in  that  they: 

1)  Correctly  specify  allowable  T.4  and  T.6  coding  variants; 

Include  photogrammetric  data  needed  to  properly  image 
(print)  and/or  edit  raster  data. 

The  registration  proposals  generated  to  =idd  these  capabilities 
are: 
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1)  Pel  Array  6DP; 

2)  Set  Direct  Colour  Response  escape; 

3)  Set  Indexed  Colour  Response  escape. 

The  following  paragraphs  explain  the  rationale  for  the  selection 
of  these  extensions. 


1.1  Introduction 

To  help  derive  a  set  of  "user  requirements*  for  raster  (image) 
data  extensions  to  computer  graphics  standards,  the  features  of 
two  well-developed  standards  with  similar  purposes  were  studied. 
They  are  the  Tag  Image  File  Format  (TIFF)  Specification  (Version 
5.0,  8  August  1988)  and  the  Xerox  Raster  Encoding  Standard  (XNS 
Standard  178506,  June,  1985.)  Each  of  these  standards  has  a 
publicly  available  specification  and  has  been  used  extensively 
for  a  variety  of  applications  for  many  years.  The  purpose  of  the 
next  few  paragraphs  is  to  present  the  results  of  an  evaluation  of 
the  features  of  two  raster  (image)  data  exchange  and  storage 
formats  and  show  how  they  relate  to  similar  proposed  extensions 
to  computer  graphics  standards. 


1.2  Requirements 

Based  upon  the  documents  reviewed,  the  following  set  of 
requirements  for  raster  data  were  developed.  These  are  not 
listed  in  any  particular  order.  The  extensions  developed  herein 
meet  all  of  these  requirements  to  a  sufficient  degree  to  make  the 
CGM  a  usable  raster  data  exchange  and  storage  mechanism  for  CALS. 

1.  Accommodate  images  of  different  sizes. 

2.  Accommodate  color  capabilities  including: 

a.  bi-level 

b.  gray-scale  monochrome 

c.  color 

3.  Accosonodate  images  of  different  resolutions. 

4.  Accommodate  images  of  different  intensity  quantizations. 

5.  Accommodate  images  of  different  encodings,  including: 

a.  CCITT  T.4 

b.  CCITT  T.6 

e.  "bitmap  encoding"  as  defined  in  DIS  8613/7. 

6.  Accommodate  pel  paths  of  at  least  0,  90,  180,  and  270 

degrees  relative  to  the  X  axis. 
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7.  Accommodate  line  progression  of  at  least  90  and  270  degrees 
relative  to  the  X  axis. 

8.  Accommodate  the  use  of  different  compression  techniques, 
including: 

a.  CCITT  T.4 

b.  CCITT  T.6 

c.  a  simple  compression  technique  for  color 

photographic  images 

9.  Accommodate  different  values  of  pel  spacing  (density), 

including  absolute  values  of  200  pels  per  25.4  mm  and  1728 
pels  per  21Smm. 

10.  Allow  for  the  specification  of  2d}solute  pel  spacing  and  line 
spacing  in  metric  units. 

11.  Allow  for  the  specification  of  relative  pel  spacing  and  line 
spacing  virtual  units. 

12.  Accommodate  different  values  of  line  spacing,  including 

absolute  values  of  at  least  3.85  and  7.7  lines/mm. 

13.  Allow  simple  images  to  be  encoded  with  little  overhead. 

14.  Include  all  important  features  of  the  Tiled  Raster 
Interchange  Format  (TRIP),  version  1.0,  as  special  cases, 
allowing  its  eventual  replacement  by  an  extended  CGM 
standard. 

15.  Include  all  Important  features  of  the  Raster  Graphics 

Content  Architecture  of  ODA  (ISO/DIS  8613,  Part  7)  as 

special  cases,  allowing  its  eventual  replacement  by  an 

extended  CGM  standard. 

16.  Include  all  important  features  of  the  Tag  Image  File  Format 
(TIFF),  version  5.0,  as  special  cases. 

17.  Include  all  important  features  of  the  Cell  Array  primitive 
of  existing  graphics  standards  as  special  cases. 

18.  Allow  the  specification  of  any  rectangular  sub-area  of  a  pel 
array  as  a  "clipped  pel  array." 

19.  Allow  the  specification  of  minimum  and  preferred  image  sizes 
in  absolute  metric  units. 

20.  Support  the  transfer  of  information  about  an  image  that  is 
required  for  editing. 

21.  Support  the  transfer  of  information  about  an  image  that  is 
required  for  printing/display. 
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22.  Support  a  wide  remge  of  color  models. 

23.  Allow  new  color  models  and  encoding  techniques  to  be  added 
without  interfering  with  the  interpretation  of  existing 
files. 


1.3  Features  of  Interpress 

The  t2d3le  below  lists  the  features  of  Interpress  in  terms  of  its 
operators  and  options  for  each  (where  applicable)  and  shows  how 
each  of  them  relates  to  the  CGM  extensions  that  have  been  defined 
as  a  result  of  this  task.  Most  Interpress  operators  have  a 
direct  correspondence  in  the  extended  CGM.  A  few  elements  are 
not  needed  due  to  the  nature  of  the  CGM. 


Feature 

imageScale 

xDimension 

yOimension 

maskimage 

colorlmage 


Description/Realization  in  CGM  Extensions 

can  be  realized  with  scaling  mode  and  metric 
scaling  factor 

nx  parameter  of  Pel  Array  GDP 
ny  parameter  of  Pel  Array  GDP 
not  supported;  probable  future  CGM  extension 
pel  array  data 


colorOperator 
GrayLinear 
GrayDensity 
(logeirithBic) 
GrayVisual 
(power  law) 
Map 

( pseudo-color) 
BuildMap 


Indexed  Colour  Response  escape 

Indexed  Colour  Response  escape 

Indexed  Colour  Response  escape 

Direct  Colour  Response  escape 
Direct  Colour  Response  escape 


imageProperties 


identification 

name 

creationTime 

modTime 


metafile  descriptor 
metafile  descriptor 

not  supported;  the  local  file  system  is  the 
proper  location  to  store  this  data,  not  the 
CGM  itself 
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scan  characteristics 

all  the  data  below  could  be  carried  in  the 
C6M  as  Application  Data 

rasterSource  name  of  the  scanner  or  raster  generator 
rasterSourcelD  usually  48  bit  Ethernet  address 
graphicsSource  the  name  of  the  device  or  system  that  created 

the  image  rom  in  which  the  raster  was  created 
imageType  Text,  line  copy,  continuous-tone,  half-tone, 

solid 

scanTransforaation 

describes  how  the  image  was  scanned 

image  processing  not  supported;  probeUaie  future  C6M  extension 
imageAperature  circular,  elliptical,  square,  rectangular, 
other,  not  applicable 

maskAperature 

imageThresholdPattem 

described  any  halftoning  or  thresholding  used 
to  create  the  image 

image  statistics  not  supported;  could  be  carried  as 

Application  Data 
compression  factor 
imageHistogram 

image  description 

not  supported;  could  be  carried  as 

Application  Data 
narrative  comments 
status 

user  identification 

not  supported;  could  be  carried  as 

Application  Data 
user  identification 
signature 

encoding 

packed  equivalent  to  encoding  of  current  Cell  Array 

in  the  C6M  and  the  bitmap  encoding  of  8613/7. 

CCITT-4 

Adaptive  not  supported 

Compressed  obsolete;  not  supported 


1.4  Features  of  TIFF 

The  table  below  lists  the  features  of  TIFF  in  terms  of  its  Tag 
Elements  and  options  for  each  (where  appliceUale)  and  shows  how 
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•ach  of  then  relates  to  the  CGM  extensions  defined  herein.  Most 
TIFF  elements  have  a  direct  correspondence  In  the  extended  CQf. 
A  few  elements  are  not  needed  due  to  the  natiire  of  the  CGM. 

FgatWrg  Description/Realization  In  CGM  Extensions 

Basic  Fields 

BitsPerSasple  local  colour  precision  parameter  of  Pel  Array 
GDP 

Colortfap  Colour  T2U3le 

ColorResponseCurves 

Direct  Colour  Response  escape 

Compression  compression  parameter  of  Pel  Array  GDP 
none 

CCITT  Group  3,  1  dimension2J. 

LZW 

GrayResponseCurve 

Indexed  Colour  Response  escape 

GrayResponseUnit 

Indexed  Colour  Response  escape 

InageLength  ny  parameter  of  Pel  Array  GDP 

InageWidth  nx  parameter  of  Pel  Array  GDP 

NewSubfileType  not  directly  supported;  could  do  with 
external  data 

a  reduced  resolution  version  of  another  image 

a  single  page  of  a  multi-page  image 

this  is  a  transparency  mask  for  another  image 

Photometric  interpretation 

can  be  realized  by  colour  specification  modes 
bilevel/grayscale  with  0  imaged  as  white 
bilevel/grayscale  with  0  imaged  as  black 
RGB 

Palette  Color  direct  colour 
Transparency  mask 

not  supported;  probable  future  CGM  extension 
PlanarConfiguration 

not  applicable;  CGM  colour  coding  modes 
preempt  this 
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fMtmrt 


Descrlptlpn/Realization  in  CGM  Eagtensions 


Predictor  used  with  LZW  coapresslon;  incorporated  in 

our  conpression  options 

ResolutlonUnit  can  be  realized  with  scaling  mode  and  metric 

scaling  factor 

SowsPerStrip  ny  parameter  of  Pel  Array  6DP;  each  strip  is 

encoded  as  a  separate  pel  array  in  the 
metafile;  each  may  have  a  different  number  of 
rows,  thereby  offering  more  flexibility  than 
TIFF 


Sa^lesPerPixel 

not  needed;  inherent  in  colour  specification 
and  coding  in  the  CGM 

StripByteCounts 

not  needed 
StripOf fsets  not  needed 

XXteaolution  can  be  realized  with  scaling  mode  and  metric 

scaling  factor 

ypesolution  can  be  realized  with  scaling  mode  and  metric 
scaling  factor 

Informational  Fields 

Artist  could  be  done  with  External  Data 

Oaterime  metafile  description 

HostCo^>uter  could  be  done  with  External  Data 

ImageOescription 

metafile  description 

Make  could  be  done  with  External  Data 

Model  could  be  done  with  External  Data 

Software  could  be  done  with  External  Data 
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Ccaq>r«8sion  comprMslon  parameter  of  Pel  Array  GDP 
CCITTGroup3 
CCITTCroup4 

Groi^SOptlons  compression  parameter  of  Pel  Array  GOP 
2-dimensional  coding 
uncompressed  mode 

fill  bits  force  SOL  to  byte  boundaries 

Groiq>40ptions  compression  parameter  of  Pel  Array  GDP 
uncospressed  mode 


OocumentName  could  be  done  with  External  Data 
PageName  could  be  done  with  External  Data 
PageNumber  could  be  done  with  External  Data 
XPosition  could  be  done  with  External  Data 
YPosition  could  be  done  with  External  Data 


2.0  Conclusion  of  Registration  for  Line  Types,  Hatch  Styles  and 
Text  Fonts 

Most  of  the  additional  registered  items  developed  during  this 
period  are  described  below  in  Section  IV.  Although  the  intention 
was  to  prepare  proposals  to  register  enough  additional  text  fonts 
to  support  the  minimum  requirements  of  IGES  and  Y14.2M-1979  and 
for  office  document  exchange,  the  entire  SC18  font  architecture 
and  its  relationship  to  character  sets  has  \indergone  significant 
revision  over  the  last  month.  These  changes  occurred  at  the  SWG 
meeting  on  DZS  9541  that  was  held  in  London  in  late  August.  A 
compromise  acceptable  to  SC18,  SC2,  and  SC24  was  developed. 

As  a  result  of  this  compromise,  graphics  standards  will  point  to 
the  same  AFIZ  (Association  for  Font  Information  Interchange) 
register  as  used  by  SC18  for  "glyphs"  and  "glyph  collections". 

(A  glyph  is  somewhat  like  a  character,  only  glyphs  can  include 
stylistic  variations  of  purely  typographic,  not  linguistic, 
significance.  A  glyph  collection  is  like  a  font.)  The 
association  between  character  codes  and  glyph  collections  (fonts) 
will  be  made  through  the  registration  process  for  graphical 
items.  (Previously,  it  had  been  agreed  not  to  use  this 
registration  process  to  register  "text  font  usage",  and  to  wait 
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instead  for  tha  SC18  raglstration  procass  to  bacona  affactiva. 
Unfortunataly,  SC18  has  dacidad  not  to  ragistar  any  associations 
batvaan  glyph  collactions  (fonts)  and  charactar  codas.) 

Dua  to  tha  additional  coaplaxity  of  praparing  taxt  ragistration 
proposals  undar  this  naw  schaaa,  and  its  nawnass  and  lack  of 
thorough  raviaw  by  all  SC18  national  bodias,  aaka  it  unwisa  to 
attaapt  such  ragistration  for  savaral  aora  aonths. 

Ona  araa  vhara  additional  ragistarad  itaas  ara  urgantly  naadad  is 
tha  araa  of  taxt.  Although  MIST  axpacts  to  avantually  davalop 
ragistarad  axtansions  basad  on  tha  SC18  work  (DP  9541) ,  that  work 
is  not  yat  staU»la  anough  to  usa  as  a  basis  for  axtansions. 
Furtharmora,  such  massiva  axtansions  to  tha  taxt  modal  in 
computar  graphics  standards  is  bayond  tha  scopa  of  this  task.  In 
tha  intaria,  a  sat  of  aight  ascapa  functions  to  maat  the 
inmadiata  needs  of  CALS  applications  ara  proposed,  complete  with 
language  bindings  to  expedite  their  processing.  This  work  will, 
of  course,  be  reviewed  by  X3H34. 


These  escapes  define  additional  text  attributes  and  give  a  way  to 
turn  them  on  and  off.  They  are: 

Set  Underline  Text 

Sat  Bold  Taxt 

Sat  Italic  Taxt 

Sat  Outlina  Taxt 

Sat  Shadow  Taxt 

Sat  Condansad  Taxt 

Sat  Extandad  Taxt 

Sat  Fully  Justifiad  Taxt 

To  saa  why  thasa  axtansions  ara  uxrgantly  naadad,  considar  this 
typical  situation.  A  pictura  contains  aight  fonts  with  the  7 
"attributes"  named  above  available  for  usa  in  any  combination 
(a.g.  bold  italic  outlina  Timas.)  This  requires  a  "font  list"  in 
tha  CGH  that  contains  40,320  attribute  combinations  for  each  of  8 
fonts,  for  a  total  of  322,560  itamsl  This  is  clearly  unworkable. 
A  future  version  of  NIL-D-COl  will  list  only  the  font  feunily  name 
in  the  font  list  (allowable  names  would  be  those  that  are 
proposed  for  registration  during  next  fiscal  year)  and  will 
require  the  usa  of  tha  escapes  proposed  to  sat  additional  font 
"style  attributes."  However,  it  is  still  premature  to  consider 
their  inclusion  in  tha  upcoming  version  of  MIL-D-CGM. 


3.0  Follow  Through  on  Previous  Registration  Proposals 

Tha  chart  below  gives  tha  status  of  each  registration  proposal 
which  is  being  sponsored  as  a  result  of  this  task  and  its  current 
status.  Tha  majority  of  tha  previous  submittals  have  completed 
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ANSI  procassing  and  are  awaiting  ISO  letter  ballot.  Due  to  the 
work  done  at  the  SC24  Tucson  meeting  this  month,  they  are 
expected  to  pass  without  serious  problems.  The  work  at  that 
meeting  lead  to  agreement  with  among  ISO  National  Bodies  that  the 
line  types  and  hatch  styles  would  be  given  "generic"  names, 
reflecting  the  fact  that  they  may  have  other  uses  beyond  the 
specific  ones  currently  envisioned. 

Several  proposals  were  dropped  due  to  lack  of  understanding  by 
the  ANSI  committee.  These  have  been  re-submitted  here  as  a 
result  of  this  task,  and  should  be  balloted  by  X3H3  as  soon  as 
possible.  Responses  to  ballot  comments  needed  by  the  X3H3 
registration  task  group  have  been  prepared  and  are  included  as 
Appendix  1. 

The  name  of  one  proposal  (Bezier  Curve)  was  revised  and  three  new 
proposals  were  created  during  this  task.  The  new  proposals  were 
devised  to  separate  line  attributes  from  edge  attributes.  This 
was  done  at  the  suggestion  of  the  C6M  group,  who  suggested  that 
the  proposals  might  not  pass  ISO  letter  ballot  otherwise. 
Modifications  to  the  other  proposals  that  were  required  to 
respond  to  comments  received  on  the  last  letter  ballot  have  also 
been  made.  This  took  considerable  effort  in  many  cases.  NIST 
also  attempted  to  align  the  proposals  as  closely  as  possible  with 
CGM  addendtim  3.  This  was  not  too  difficult  since  CGM  addendum  3 
is  based  almost  word  for  word  on  NIST  registration  proposals, 
with  only, a  few,  mostly  inconsequential  chatnges  made. 

The  language  bindings  prepared  by  X3R34  for  the  Rational  B- 
spline  and  Parametric  Spline  proposals  were  incomplete.  Many 
other  bindings  contained  whar  appeared  to  be  serious  technical 
mistakes.  NIST  completed  the  unfinished  bindings  and  corrected 
the  incorrect  ones.  These  bindings  will  be  referred  to  X3H34  for 
review. 


Clagg  9t  ItCT 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 

Linetype 


Status  of  Registration  Proposals 


User-specified  dash  pattern 

Single  arrow 

Single  dot 

Double  arrow 

Stitch  line 

Chain  line 

Center  line 

Phantom  line 

Break  line  -  style  1 

Break  line  -  style  2 

Hidden  line 


Status 

included  with  this  report 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
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Status  of  Ragistratlon  Proposals 


<P;affg..9f  Lt«i 


Status 


Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 
Hatchstyle 
Hatch  style 

Hatchstyle 

Hatchstyle 

Hatchstyle  . 

Hatch  style 

Hatchstyle 

Hatchstyle 

Hatchstyle 

Hatchstyle 


Cast  iron  and  general  use 
for  all  materials 

Steel 

Bronze,  brass,  copper,  and 
compositions 
White  medal,  zinc,  lead, 
babbitt  and  alloys 
Magnesium,  aluminum,  and 
aluminum  alloys 
Riibber,  plastic,  euid 

electrical  Insulation 
Cork,  felt,  fedaric,  leather, 
and  fibre 
Sound  insulation 
Thermal  insulation 
Titanium,  and  refractory 
material 
Concrete 

Marble,  slate,  glass, 
porcelain ,  etc . 

Earth  « 

Rock 

Sand 

Water  and  other  liquids 
with  grain  wood 
Across  grain  wood 


SC24  Letter  Ballot 
SC24  Letter  Ballot 

SC24  Letter  Ballot 

SC24  Letter  Ballot 

SC24  Letter  Ballot 

SC24  Letter  Ballot 

SC24  Letter  Ballot 
SC24  Letter  Ballot 
SC24  Letter  Ballot 

SC24  Letter  Ballot 
SC24  Letter  Ballot 

SC24  Letter  Ballot 
withdrawn 
SC24  Letter  Ballot 
SC24  Letter  Ballot 
included  with  this  report 
included  with  this  report 
included  with  this  report 


Escape 

Escape 

Escape 

Escape 

Escape 

Escape 

Escape 

Escape 

Escape 

Escape 


Set  dash 

Set  line  miter  limit 

Set  line  cap 

Set  line  join 

Set  edge  miter  limit 

Set  edge  cap 

Set  edge  join 

Set  conic  arc  transformation 
matrix 

Set  direct  colour  response 
Set  indexed  colour  response 


included  with  this  report 
included  with  this  report 
included  with  this  repoxrt 
included  with  this  report 
included  with  this  report 
included  with  this  report 
included  with  this  report 

included  with  this  report 
included  with  this  report 
included  with  this  report 


GOP 

GDP 

GDP 

GDP 

GDP 


Conic  arc 

Parametric  spline  curve 
Rational  B-spline  curve 
Cubic  Bezier  curve 
Pel  array 


included  with  this  report 
included  with  this  report 
included  with  this  report 
included  with  this  report 
included  with  this  report 
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3.1  Presantation  of  Saction  Lining 


Tha  following  tabla  stumarizas  how  various  section  lining  symbols 
used  in  anglnaaring  drawings  should  be  "presented”  using  hatch 
styles  in  Computer  Graphics  standards.  NIST  has  used  the  names 
tinder  which  the  proposals  ware  originally  submitted,  but  these 
should  be  replaced  by  tha  Internationally  registered  names  when 
they  are  assigned  by  tha  Registration  Authority.  These,  too, 
will  become  part  of  some  future  version  of  MIL-IV-CGM,  but  it  is 
still  premature  for  their  inclusion  at  this  time. 


Saeteion  TAnina  Symbols  PlMSHtatiCT  M 

in  Graphic  Standards 

Cast  iron  and  general  use  for  all  materiails 

Cast  iron  and  general  use  for  all 
materials  (Note:  This  is  similar  tc 
hatch  index  3 ,  but  has  additional 
rendition  requirements  beyond  those 
specified  in  the  graphics  standards) 

Steel  Steel 

Bronze,  brass,  copper,  and  compositions 

Bronze,  brass,  copper,  and  compositions 

White  medal,  zinc,  lead,  babbitt  and  alloys 

White  medal,  zinc,  lead,  babbitt  and 
alloys  (Note:  This  is  similar  to  hatch 
index  6,  but  has  additional  rendition 
requirements  beyond  those  specified  in 
the  graphics  standards) 

Magnesium,  aluminum,  and  aluminum  alloys 

Magnesixim,  aluminum,  and  alumin\ua  alloys 

Rubber,  plastic,  and  electrical  insulation 

Rubber,  plastic,  and  electrical 
insulation 

Cork,  felt,  fabric,  leather,  and  fibre 

Cork,  felt,  fabric,  leather,  and  fibre 

Sound  insulation  So\ind  insulation 

Thermal  insulation  Thermal  insulation 

Titanium,  and  refractory  material 

Titanium,  and  refractory  material 


13 


Sacstlon  lAniiui  Symbola 


Praantation  as  Hatchstvles 
in  graphic  Standards 


Elactric  windings,  slsctrosagnsta,  rssistanes,  etc. 

USAS  hatch  index  5,  horizontal/verticaX 
crosshatch 

Concrete  Concrete 

Marble,  slate,  glass,  porcelain,  etc. 

Marble,  slate,  glass,  porcelain,  etc. 

Earth  render  as  a  combination  of  the  Rock 

hatch  index  and  the  S^uld  hatch  index 

Rock  Rock 

Sand  Sand 

Water  and  other  liquids  Water  and  other  liquids 

With  grain  wood  With  grain  wood 

Across  grain  wood  Across  grain  wood 


3.2  Presentation  of  ULne  Conventions 

The  following  table  stunmarizes  how  various  line  conventions  are 
used’  in  engineering  drawings  should  be  "presented”  using 
linetypes  in  Computer  Graphics  standards.  NIST  has  used  tile 
names  under  which  we  originally  submitted  the  proposals,  but 
these  should  be  replaced  by  the  internationally  registered  neunes 
when  they  are  assigned  by  the  Registration  Authority.  In  this 
table,  the  "thin”  and  "thick"  linewidths  refer  to  the  two  widths 
required  by  paragraph  3.1  of  ANSI  Yl4 . 2M~1979 .  These,  too,  will 
become  part  of  some  future  version  of  MIL*0-CGM,  but  it  is  still 
premattire  for  their  inclusion  at  this  time. 


Laa..CqnY«ilfei<?na 

Lsible  lines 
Ldden  lines 

iction  lines 
inter  lines 


Presentation  as  Linetypes 

ixL  gmhig-S^darta 

presented  as  thick  line  in  solid  linetype 

Hidden  line  (Note:  similar  to  dash  linetype, 
only  with  additional  rendition  requirements) 

presented  as  thin  line  in  solid  linetype 

Center  linetype 
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I^na  Convantiona 

SysDMtry  lines 
Oinension  lines 

Extension  lines 
Leaders 

Cutting-plane  lines 


viewing  plane  lines 


Break  lines 


Phantom  lines 
Stitch  lines 
Chain  lines 


Presentation  as  Linetvoes 
in  Graphic  Standards 

Center  linetype 

presented  using  one  or  two  lines;  if  two 
lines  are  used,  each  ends  in  a  single  arrow; 
if  a  single  line  is  used  (with  the  dimension 
"text"  outside  the  line) ,  a  Double  arrow  type 
is  used 

Single  arrow  linetype 

Single  dot  or  Single  arrow  linetype 

presented  as  a  set  of  three  graphical  lines, 
related  as  described  in  paragraph  3.7  of  ANSI 
Y14.2M-1979;  two  are  solid  thick  lines  with 
Single  arrow  style  (indicating  direction  of 
sight) ;  the  other  is  a  thick  line  using 

Hidden  linetype 

presented  as  a  set  of  three  graphical  lines, 
related  as  described  in  paragraph  3.7  of  ANSI 
Y14.2M-1979;  two  are  solid  thick  lines  with 
Single  arrow  style  (indicating  direction  of 
sight) ;  the  other  is  a  thick  line  using 

Phantom  linetype 

both  styles  of  break  line  specified  in 
paragraph  3.7  of  ANSI  Y14.2M-  1979  are 
allowable  presentation  styles;  lines  as 
described  in  3.8(a)  are  presented  using  Break 
line  -  style  1;  lines  as  described  in  3.8(b) 
are  presented  using  Break  line-style  2 

Phantom  line  linetype 

Stitch  line  linetype 

Chain  line  linetype 
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IV.  CONCLDSIONS  AMD  BECQMMENDATIONS 

It  must  be  stressed  that  tinely  processing  of  the  registration 
proposals  developed  this  fiscal  year  requires  sponsorship  through 
the  ISO  process  and  response  to  requests  for  changes  as  the 
result  of  standards  comaittee  ballots. 

Successful  completion  of  the  necessary  text  font  usage 
registration  proposals  should  be  undert2dcen  as  soon  as  possible. 
Without  these  proposals,  the  other  Items  developed  thus  far  will 
be  less  useful  as  high-quality  text  cemnot  be  transferred  in 
metafiles. 


1.0  Revised  Registration  Proposals 

The  following  pages  describe  all  the  revised  registration 
proposals  as  a  result  of  this  task. 


16 


ProDosal  Number:  1 


.Presentation  date  of  proposal:  1 10  April  1987 


ANSI 


Clast  of  Qraphleal  Itetm  UNETYPE  


Name:  user-specified  dash  pattern 


Deaerlptlon 


The  user-specified  dash  pattern  linetype  consists  of  alternating  dashes  and  spaces  as  speofisd  in  the  current 
user-specified  dash  pattern.  This  linetype  is  intended  for  use  in  high-quality  graphical  applications  where  the  user 
of  the  standard  maintains  precise  control  over  the  manner  in  which  the  linetype  is  rendered  by  the  use  of 
individually  specified  attrftxjtes.  Although  its  use  is  not  preduded  in  applications  that  choose  to  use  bundled 
attrft)utes,  the  intent  of  the  user  to  exercise  a  high  degree  of  control  over  the  rendition  of  graphical  output  wUI  be 
compromised,  especially  in  metafile  appiicaliona. 


Additional  Comments 


This  registration  proposal  is  accompanied  by  a  proposal  to  register  an  escape  function  -  Set  Dash  -  that  defines  the 
current  user-specified  dash  pattern.  It  is  intended  that  these  proposals  be  processed  together. 

This  linetype  is  not  intended  to  be  used  as  an  edgetype. 


Justification  for  Inclusion 


User  specified  linetypes  are  needed  to  support  the  requirements  of  office  document  exchange  and  publishing.  They 
are  commonly  found  in  widely  available  proprietary  graphics  systems. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those  defined  in  5.4.1. 

2)  ISO  8632  (COM)  -  Specifies  a  registered  linetype  to  supplement  those  defined  in  5.7.2. 

3)  ANSI  Y14.2M-1979  -  Line  Conventions  and  Lettering. 
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Proposal  NumbTtl36 


Oats  of  Prsssntatlon:  1 10  April  1987 


Class  of  Qraphleal  Itsm:  I  ESCAPE 


EmnoEmai 


Function  Idontifisr:  I  Sot  Oash 


Oaserlptlon 


This  sscaps  function  sots  ths  value  for  the  ussr* *spocifisd  (ragistsrsd)  Unstyps.  This  pattom  is  used  during 
subsequent  interpretation  of  graphical  primitivos  that  use  linetype  attrfoutes.  See  attached  sheet  for  addHionai 
details. 


Additional  Comments 


_  Justification  for  inclusion 


Required  to  support  the  user^specified  dash  pattern  linetype.  User  specified  line  types  are  commonly  found  in 
proprietary  graphics  systems.  They  are  needed  to  support  foe  requirements  of  office  document  exchange  and 
publishing.  The  linetype  capabilities  proposed  hero  are  adapted  from  those  in  foe  PostScript  language,  which  was 
developed  by  Adobe  Systems  Incorporated,  and  whose  spedfiealion  has  been  placed  in  foe  public  domain. 


Relationship  to  Standards 


1 )  ISO  7942  (QKS)  •  Specifies  a  registsrsd  escape  as  defined  in  5.2. 

2)  ISO  8632  (COM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  regisforsd  escape. 

*At  present  at  foe  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Daaeriptlon: 


Sat  Dash  sets  a  dash  pattern  state  value  in  the  graphics  states 
controlling  the  dash  pattern  used  during  subsequent  interpretation 
of  graphics  primitives  that  are  drawn  with  the  registered  linetype 
value  of  "user-specified  dash  pattern"  (linetype  TBD) .  If  the  array 
of  dash  pattern  lengths  is  empty  (i.e^  the  number  of  lengths  is 
zero)  r  the  linetype  is  equivalent  to  solid.  This  is  the  default 
value.  If  the  array  of  dash  pattern  lengths  is  not  empty/  the 
affected  primitives  are  drawn  with  dashed  lines  whose  pattern  is 
given  by  the  elements  of  the  array/  which  must  be  non-negative 
numbers  and  not  all  zero. 

The  elements  of  the  array  of  dash  pattern  lengths  are  interpreted 
in  sequence  as  relative  distances  along  the  primitive.  These 
distances  alternately  specify  the  length  of  a  gap  between  dashes . 
The  contents  of  the  array  are  used  cyclically/  that  is  when  the  end 
of  the  array  is  reached/  the  pattern  starts  over  at  the  beginning. 

Dashed  lines  wrap  around  curves  and  corners  just  as  solid  lines  do. 
The  ends  of  each  dash  are  treated  with  current  line  cap/  corners 
within  a  dash  are  treated  with  current  line  join.  No  measures  are 
provided  to  coordinate  the  dash  pattern  with  features  of  an  output 
primitive . 

The  offset  value  may  be  thought  of  as  the  "phase"  or  the  dash 
pattern  relative  to  the  start  of  the  path.  It  is  interpreted  as  a 
distance  into  the  dash  pattern  at  which  the  pattern  should  be 
started.  Before  beginning  output  of  the  dash  pattern/  the  elements 
of  the  array  of  dash  pattern  lengths  are  cycled  through/  and  the 
distances  of  alternating  dashes  and  gaps  added  up/  but  without 
generating  any  output.  When  the  offset  distance  into  dash  pattern 
has  been  reached/  the  primitive  is  drawn  (from  its  beginning)  using 
the  dash  pattern  from  the  point  that  has  been  reached. 

When  continuity  is  set  to  restart,  each  portion  of  a  primitive 
(e.g.  each  line  segment  within  a  polyline)  is  treated 
independently;  i.e.  the  dash  pattern  is  restarted  (and  offset 
applied)  at  the  beginning  of  each  portion.  When  continuity  is  set 
to  continuous,  the  dash  pattern  is  not  restarted  in  going  from  one 
portion  of  a  primitive  to  the  next. 
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1)  CGM  ruaetlonal  Specification  (reference  ISO  8632  C6M; 
Part  1:  Functional  Description) 


The  elements  of  the  array  of  dash  pattern  lengths  are  interpreted 
in  sequence  as  distances  in  VDC  units  along  the  primitive.  The 
offset  value  is  in  VDC  units.  A  functional  description  of  the  Set 
Dash  escape  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 
offset  (VDC) 

continuity  (one  of:  restart,  continuous)  (E) 
list  of  lengths  (nVDC) 
dash  pattern  lengths  array 

Items  for  Data  Record: 

If  VDC  TYPE  integer  was  selected: 

Integer  IL  3  number  of  lengths 

Integer  IA(1)  offset 

Integer  IA(2)  continuity 

Integer  IA(3)  number  of  lengths 

Integer  IA(4)  first  length 

Integer  IA(5)  second  length 

•  «  « 

Integer  lA (2'1-number  of  lengths)  last  length 
Integer  RL  0 

Integer  SL  0 

If  VDC  TYPE  real  was  selected: 

Integer  IL  2 

Integer  IA(1)  number  of  lengths 

Integer  IA(2)  continuity 

Integer  RL  1  number  of  lengths 

Real  RA(1)  offset 

Real  RA(2)  first  length 

Real  RA(3)  second  length 

•  •  • 

Real  RAd-t-number  of  lengths)  last  length 
Integer  SL  0 

Data  Record  Description: 

The  parameters  define  the  offset,  continuity,  number  of  dash 
pattern  lengths,  and  the  dash  pattern  lengths. 
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2)  CGH  Saeedings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


3)  6XS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

The  set  dash  escape  is  applicable  at  GKS  level  Oa.  A  functional 
description  of  its  parameters  is  given  below: 


Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

continuity  (RESTART,  CONTINUOUS)  E 

number  of  lengths  I 

dash  pattern  lengths 

array  nxR 


output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  G/COP,  WSOP,  WSAC,  or  SGOP 
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••/  x^guag*  oinaing  (rezerence  ISO  OIS  8651/1  GKS 

Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  Is  proposed  for  the  "GEpqrs”  form 
(as  defined  In  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  Is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (CONTr  DIMLEN,  OFFSET ^  LEN) 


Input  Parameters: 

INTEGER  CONT 
INTEGER  DIMLEN 

REAL  OFFSET 
REAL  LEN (DIMLEN) 

Output  Parameters : 

NONE 


continuity  (RESTART^  CONTINUOUS) 
dimension  of  the  dash  pattern  lengths 
array 

offset  Into  dash  pattern 
dash  pattern  lengths  array 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pac)c  Data  Record  function  (GPRLC)  : 


INTEGER  IL 
INTEGER  IA(  1  ) 
INTEGER  IA(  2  ) 
INTEGER  RL 
REAL  RA(  1  ) 
REAL  RA(  2  ) 
REAL  RA(  3  ) 


2 

continuity  (RESTART,  CONTINUOUS) 
number  of  dash  pattern  lengths 
l<f  number  of  dash  pattern  lengths 
offset 

first  length 
second  length 


•  •  • 

REAL  RA(1  *  number  of  dash  pattern  lengths) 

last  length 

INTEGER  SL  0 


Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL 
INTEGER  RL 
INTEGER  SL 


0 

0 

0 


5)  ffMcal  laaguag*  blading  (referance:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape"  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GEscapeContlnulty  -  (GVEscapeRestart,  GVEscapeContlnuous) ; 

GREscapeDataIn  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

Continuity  ;  GEscapeContlnulty; 

NumberLengths  :  INTEGER; 

Patterns  :  REAL  ) ; 

END; 

GREscapeDataOut  ■■  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 

l5  ()  ;  (*Null  Record*) 

END; 
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6)  6KS  Ada  laaguaga  biadiag  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part 3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS  ESCAPE.  GKS 
Ada  provides  a  data  type  packager  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_OASH"  form  (as  defined  in 
Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is: 


— Escape  function  for  a  user  specified  dash  pattern. 

— Data  types  ESCAPE_ID  and  ESCAPEJFLOAT  are  defined  in  package 
— GKS_ESCAPE . 

—Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package~GKS_ESCAPE  is 

type  CONTINUITY_CHOICE  is  (RESTART, CONTINUOUS) ; 
type  DASH  PATTERN_LENGTHS_ARRAY  is  array 

(SM)^L_NATDRAL  range  <>)of  ESCAPE  FLOAT: 
type  SET_DASH__DATA_RECORD  (NUMBER_0F_LE5fGTHS :  SMALL_NATURAL :  -  { )  )  is 
record 

CONTINUITY  :in  CONTINUITY_CHOICE : 

DASH_PATTERN  LENGTHS  :in  DASH_PATTERN_LENGTH_ARRAY 
”  ( 1 . . NUMBER_OF_LENGTHS ) ; 

end  record; 

procedure  SET  DASH 

(ESCAPE  IDENTIFIER  :in  ESCAPE  ID; 

DASH  RECORD  :in  SET  DASH  DATA  RECORD); 


—more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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Proposal  NutnbTtfa? 


10  April  1987 


Sponsorin 


Clast  of  Qraphleal  Itam:  I  ESCAPE 


Spocifle  Eaeapo  I  Function  Idontiflar:  I  Sat  Una 


Oaacriptlon  _ 


This  aacapa  function  acts  a  value  for  tha  currant  lina  cap.  This  value  is  to  datarmina  the  shape  put  at  the  ends  of 
portiona  of  Hnaa  and  curves  during  aubaaquant  Intaipratation  of  graphical  primitivaa  that  use  linatypo  attributes. 
See  attached  sheet  for  additional  details. 


Additional  Comments 


Justification  for  Inclusion _ 


User  specified  Una  caps  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  pub^irtg.  The  linetype  capabilities  proposed  hare  are  adapted 
from  those  In  tha  PostScript  language,  which  was  developad  by  Adobe  Systems  Incorporated,  and  whose 
specification  has  been  placed  in  the  public  domain. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (COM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*AI  present  at  the  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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D««eripfeiQn; 

S«t  Lln«  Cap  sets  the  current  line  cap  value  in  the  graphics 
state  to  the  value  specified  by  the  line  cap  indicator.  This 
establishes  the  shape  to  be  put  at  the  ends  of  open  subportions  of 
graphics  output  primitives  whose  components  are  lines  or  curves. 
The  following  line  cap  values  are  supported: 

butt  cap  :  the  line  is  squared  off  at  the  endpoint;  there  is 
no  projection  beyond  the  endpoint. 

round  cap  :  a  semicircular  arc  with  diameter  equal  to  the 
line  width  is  drawn  around  the  endpoint  and  filled.  The 
drawn  line  thus  projects  beyond  the  endpoint. 

projecting  square  cap  :  the  line  is  squared  off  at  a 
distance  equal  to  half  the  line  width  beyond  the  endpoint . 

Other  values  are  reserved  for  future  registration  and 
standardization.  The  default  value  is  butt  cap. 

Bnlationahip _ tfi _ particular  standards; 


1)  004  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Line  Cap  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

line  cap  indicator  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

line  cap  indicator 
0 
0 


The  parameter  defines  the  line  cap  index. 
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2)  CQI  Ineodings  (referenc«  ISO  8632  CGM;  Parts  2,3,  A) 

All  encodings  will  be  handled  in  the  saune  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


3)  6KS  Functional  Specification  (reference  ISO  7942  GKS 

Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 
description  of  its  parameters  is  given  below: 


Name 

escape  function  identifier 


Values 

as  assigned 


input  data  record: 

line  cap  indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors: 


GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (LNCAP) 

Input  Parameters : 

INTEGER  LNCAP  line  cap  indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 


Output  Parameters : 
NONE 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  estape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  line  cap  Indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 

5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE”  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEscapeLineEndType  >•  (GVEscapeButt,  GVEscapeRound, 

GVEscapeProjectingSquare) ; 

GREscapeDataIn  •  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

Linecap  :  GEscapeLineEndType) ; 

End; 

GREscapeDataOut  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record  *) 

END; 


6)  6KS  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package^  GKS_TyPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_LINE_CAP’*  form  (as  defined  in 
Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is : 


— Escape  function  for  a  set  line  cap. 

— Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
• — Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS__TYPES; 
package  GKS_ESCAPE  is 

type  LINE_CAP_INDICATOR_TYPE  is  (BUTT,  ROUND,  PROJECTING  SQUARE) ; 
LINE_CAP_ INDICATOR_VALUE  :in  LINE_CAP_INDICATOR_TYPE; 

procedure  SET_LINE_CAP 

(ESCAPE_IDENTIFIER  : in  ESCAPE_ID: 

LINE_CAP_INDICATOR_VALUE  : in  LINE  CAP  INDICATOR  TYPE); 


— more  ESCAPE  procedures  can  be  inserted  here 

•  * 

end  GKS  ESCAPE; 
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ProDosal  Numbar:  38 


10  April  1987 


SPfenaortn 


Tnminiiraii 


Clast  of  Qraphleal  Itam:  I  ESCAPE 


Spoclfle  Eseapa  I  Function  Idantiriar:  I  Set  Lina  Mitra  Limit 


Oascriptlon 


This  eseapa  function  sats  a  valua  for  tha  current  line  mitra  limit  This  vaiua  helps  determine  the  shape  put  at 
comers  between  portions  of  lines  and  curves  during  aubsaquant  interpretation  of  graphical  primitives  that  use 
linatypa  attributes.  Its  purpose  is  to  placa  a  limit  on  how  kmg  a *  *spiko"  can  emanate  from  the  join  of  two 
portions  of  a  line  or  curve  primitiva  by  "truncating*  long  mitra  joins  into  bevel  joins.  Sea  attached  sheets  for 
additional  details. 


Additional  Comments 


Justification  for  Inclusion  _ 


User  specified  mitre  limits  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing.  The  linetype  capabilities  proposed  here  are  adapted 
from  those  in  the  PostScript  language,  which  was  developed  by  Adobe  Systems  Incorporated,  and  whose 
specification  has  been  placed  in  the  public  domain. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Daaerlption: 


Sat  Lin*  Mltr«  Limit  sets  the  current  line  mitre  limit  value  in 
the  graphics  state  to  mitre  length  specifier,  which  must  be  a 
number  greater  than  or  equal  to  1.  Mitre  limit  is  a  dimensionless 
number  that  controls  the  treatment  of  corners  between  portions  of 
line  and  curve  output  primitives  when  mitre  joins  have  been 
specified  (see  Set  Line  Join)  .  (Set  Edge  Mitre  Limit  and  Set 
Edge  Join  provide  similar  capabilities  for  the  edges  of  filled 
primitives.)  When  portions  connect  at  a  sharp  angle^  a  mitre  join 
results  in  a  spike  that  extends  well  beyond  the  connection  point. 
The  purpose  of  the  mitre  limit  is  to  cut  off  such  spikes  when  when 
they  become  objectionably  long. 

At  any  given  corner^  the  mitre  length  is  the  distance  from  the 
point  at  which  the  inner  edges  of  the  curve  or  line  portions 
intersect  to  the  point  in  which  the  outside  edges  of  the  portions 
intersect  (i.e.,  the  diagonal  length  of  the  mitre).  This  distance 
increases  as  the  angle  between  the  portions  decreases.  Whenever  the 
ratio  of  the  mitre  length  to  the  line  width  exceeds  the  line  mitre 
limit  parameter  and  is  also  greater  than  1.415,  a  bevel  is 
introduced  at  the  join  perpendicular  to  the  angle  bisector  and  at 
the  mitre  limit.  (Note  that  this  is  not,  in  general  equivalent  to 
introducing  a  bevel  ioin  when  this  limit  is  reached.  Introducing 
such  a  join  causes  discontincus  behaviour,  where  small  changes  in 
the  angle  between  the  segments  results  in  radically  different 
appearances.)  Whenever  the  ratio  of  tne  line  mitre  length  to  the 
line  width  exceeds  the  line  mitre  limit  parameter  and  is  also  less 
than  or  equal  to  1.415  (that  is,  when  the  line  mitre  limit 
parameter  is  between  1  and  1.415  inclusive),  a  bevel  join  is 
implemented  at  the  mitre  limit. 

The  ratio  of  line  mitre  length  to  line  width  is  directly  related  to 
the  angle  <|>  between  the  segments  by  the  formula: 

mitre  length  /  line  width  -  1  /  sin  {^f2) 

Examples  of  line  mitre  limit  values  are:  1.415  cuts  off  miters 
(converts  them  to  bevels)  at  angles  less  than  90  degrees,  2.0  cuts 
off  miters  at  angles  less  than  60  degrees,  and  10.0  cuts  miters  off 
at  angles  less  than  11  degrees.  The  default  value  of  line  mitre 
limit  is  10.  Setting  the  line  mitre  limit  to  1  cuts  off  miters  at 
all  angles  so  that  bevels  are  always  produced  even  when  miters  are 
specified.  The  lengths  in  the  above  formula  must  be  in  the  same 
units  (WC,  VDC,  etc.)  and  cancel  out  to  yield  a  dimensionless  line 
mitre  limit  value.  Line  mitre  limit  applies  to  line  and  curve 
elements . 


Rtlltioaahip _ to  particular  standards ; 


1)  C6M  Fuactional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Line  Mitre  Limit  escape 
parameters  Is: 

Parameters : 

function  Identifier 


data  record  (D) : 
mitre  length  (R) 

Items  for  Data  Record: 

Integer  IL 
Integer  RL 
Real  RA(1) 

Integer  SL 

Data  Record  Description: 

The  parameter  defines  the  line  mitre  length. 

2)  CGM  encodings  (reference  ISO  8632  CGM;  Parts  2^3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  Items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"/  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


(I)  as  assigned 
Authority 


by  the  Registration 


0 

1 

mitre  length 
0 
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3)  6K8  ruaetlonal  Oascription  (reference  ISO  7942  6KS 

functional  description) 

This  escape  is  applicable  at  level  Oa  of  GKS.  A  functional 
description  of  its  parameters  is  given  below: 

Marne  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

mitre  length  R 

output  data  record: 
none 

Errors : 

8  GKS  not  In  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  ffSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (MITRE) 

Input  Parameters: 

REAL  MITRE  mitre  length 

Output  Parameters : 

NONE 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  esdape  through  the  GESC  function  of  Paragraph  9.3  of  the  6KS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


INTEGER  IL 
INTEGER  RL 
REAL  RA(  1  ) 
INTEGER  SL 


0 

1 


mitre  length 
0 


Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 


5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GESCAPE**  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GREscapeOataIn  •  Record 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

MltreLength  :  REAL  ) ; 

END; 

GREscapeDataOut  •  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 

1:  0  ;  (*Null  Record  *) 

END; 
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6)  6KS  Ada  langoaga  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_LINE_MITRE__LIMIT"  form  (as 
defined  in  Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is : 


— Escape  function  for  a  set  line  mitre  limit. 

— Data  types  ESCAPE_ID  and  ESCAPE_FLOAT  are  defined  in  package  GKS 
— GKS_ESCAPE, 

— Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

MITRE_LENGTH  :in  ESCAPE__FLOAT; 

procedure  SET__LINE_MITRE_LIMIT 

(ESCAPE^IDENTIFIER  : in  ESCAPE_ID; 
MITRE  LIMIT  : in  MITRE  LENGTH; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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PropoMi  Number:  1 39 


Date  of  Preaentatlon 


Lj'i-jLiTTriit-Mmmgn 


Claes  of  Qrabhleal  Item 


■I^Sl 


Ifle  Escape  i  Function  Identifier:  I  Sal  Una  Join 


Description 


This  escape  function  sots  a  value  for  the  currant  line  join.  TMa  value  is  to  determine  the  shape  put  at  comers 
between  portions  of  lines  and  curves  during  subsequ^  interpretation  of  graphical  primitives  that  use  Hnetype 
attributes.  See  attached  sheet  for  additional  detals. 


Additional  Comments 


_  Justification  for  Inclusion 


User  specified  line  joins  are  commonly  ftxind  in  proprietary  graphics  systems.  They  are  noedsd  to  support  the 
requiremenis  of  office  document  exchwge  and  publishing.  The  Rrmtype  capabilities  proposed  here  are  adapted 
from  those  in  the  PostScript  language,  which  was  developed  by  Adobe  Systems  Incorporated,  and  whose 
specification  has  been  placed  in  the  public  domain. 


_  Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Spedfies  a  registered  esc^w  as  defined  in  5.2. 


2)  ISO  8632  (COM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Ptacriation; 


S«t  Lift*  Join  sets  the  current  line  join  state  In  the  graphics 
state  to  line  join  indicator.  This  establishes  the  shape  to  be  put 
at  the  corners  between  portions  (line  or  curve  segments)  of  line 
and  curve  graphical  output  primitives.  The  following  line  join 
values  are  supported: 

mitre  join  :  the  outer  edge  of  the  two  portions  are  extended 
until  they  meet  at  a  point.  (Note  that  the  mitre  limit  value 
may  affect  the  ajppearance  of  these  joins.) 

sound  join  :  a  circular  arc  with  diameter  equal  to  the  line 
width  Is  drawn  around  the  vertex  between  the  adjoining 
segments  and  Is  filled  In,  producing  a  rounded  corner. 

bevel  join  :  the  meeting  portions  are  finished  with  butt  end 
cap  and  the  resulting  triangular  notch  Is  filled  In. 

Other  values  are  reserved  for  future  registration  and 
standardization . 

Join  styles  are  significant  only  at  points  where  consecutive 
portions  of  a  line  or  curve  connect  at  an  angle;  portions  that  meet 
or  Intersect  fortuitously  receive  no  special  treatment. 
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_ ittndigda ; 


1)  CGM  nanetloMl  Specification  (reference  ISO  8632  C6M; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Line  Join  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

line  join  indicator  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

line  join  indicator 
0 
0 


The  parameter  defines  the  line  join  index. 


2)  CGK  Encodings  (reference  ISO  8632  CGM;  Parts  2^3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string**/  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is/  the  data  record  items) / 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding/  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  SXS  Functional  Oaseription  (reference  ISO  7942  GKS 
functional  description) 

This  escape  Is  applicable  at  level  Oa  of  GKS.  A  functional 
description  of  Its  parameters  Is  given  below: 

Maae  Values  Data  Type 

escape  function  Identifier  as  assigned  N 

Input  data  record: 

line  join  indicator  (MITRE,  ROUND,  E 

BEVEL) 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  Is  proposed  for  the  "GEpqrs"  form 
(as  defined  In  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  Is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (LNJOIN) 

Input  Parameters: 

INTEGER  LNJOIN  line  join  indicator  (MITRE,  .ROUND, 

BEVEL) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  1A(  1  )  line  join  indicator  (MITRE,  ROUND, 

BEVEL) 

INTEGER  RL  0 

INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Pascal  laagcaga  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  ”1”  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GEscapeLineJoin  -  (Mitre/  Round/  Bevel) ; 

GREscapeOataIn  •  RECORD 

CASE  Escape Id  GTEscapeOataTag  of 

1:  ( 

Line join  :  GEscapeLineJoin) ; 

END; 

GREscapeDataOut  *  RECORD 

CASE  Escape Id  GTEscapeOataTag  of 

1:  0  ;  (*Null  Record*) 

END; 


6)  GKS  Ada  Language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  P.art3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  pacJcage  name  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  pac)cage/  GKSJTYPES  which  provides  type 
declarations .  ~~ 

The  binding  for  the  "procedure  SET_LINE  JOIN"  form  (as  defined  in 
Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is: 


— Escape  function  for  a  set  line  join 

— Data  type  ESCAPE__ID  is  defined  in  package  GKS_ESCAPE. 
— Other  data  types"are  defined  in  package  GKS_TYPES. 


with  GKS__TYPES; 
use  GKS_TYPES; 
package  GKS  ESCAPES  is 

type  LfNE_JOIN_INDICATOR_TYPE  is  (MITRE/  ROUND/  BEVEL) ; 
LINE_JOIN_INDICATOR__VALUE  :  in  LINE_JOIN_INDICTOR_TYPE; 

procedure  SET_LINE_JOIN 

(ESCAPE  IDENTIFIER  :in  ESCAPE_ID; 

LINE  JOIN  INDICATOR  VALUE: in  LINE  JOIN  INDICTOR  TYPE  ); 


— more  ESCAPE  procedures  can  be  Inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


R»latlon8hlp  to  Standards 

1)  ISO  7942  (GKS)  •  Spactflas  a  ragistared  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  GOP  as  definad  in  5.6.10. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  GOP.  (See  attached  sheets). 

*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  tseen 
approved  by  ISO  council. 
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Daaerlpfeioni 

Cubic  Bcsicr  Curve  adds  a  Bezier  cubic  curve  between  the  first 
point r  referred  to  here  as  Yq)  and  the  fourth  point  {X3,  Yj) , 

using  (X^f  Y^)  and  {X^fY^)  as  the  Bezier  cubic  points. 

The  four  points  define  the  shape  of  the  curve  geometrically.  The 
curve  starts  at  {Xq,  Yq)  ,  it  is  tangent  to  the  line  from  (Xg,  Yg)  to 
(Xj,  Yi)  at  that  point,,  and  it  leaves  the  point  in  that  direction. 
The  curve  ends  at  (Xj,  Y^) ,  it  is  tangent  to  the  line  from(  X^r  Yg) 
to  (Xg,  Yg)  at  that  point,  and  it  approaches  the  point  from  that 
direction.  The  lengths  of  the  lines  (Xg,  Yg)  to  (Xg,  Yj)  and 
(Xg,  Yg)  to  (Xg,  Yg)  represent  in  some  sense  the  "velocity"  of  the 
path  at  the  endpoints.  The  curve  is  always  entirely  enclosed  by  the 
convex  quadrilateral'  defined  by  the  four  points. 

The  mathematical  foundation  of  a  Bezier  cubic  curve  is  derived  from 
a  pair  of  parametric  cubic  equations: 


x(t}  -  +  c^t  +  Xg 

y(t)  -  Byt^  +  byt^  +  Cyt  ^  Yg 

The  cubic  section  produced  by  Cubic  Bezier  Curve  is  the  path 
traced  by  x(t)  and  y(t)  as  t  ranges  from  0  to  1.  The  Bezier  control 
points  corresponding  to  this  curve  are: 


Xi  •  Xg  +  c^/3 
Xg  •  Xg  +  (c„  + 

Xg  •  Xg  -h  c„  +  b„  +  a„ 


Vi  •  Vo  *  Cy/3 
Ys  Yl  *  <<^y  +  ^y>  /•? 
Y3  •  Yo  *  '^y  *  by  *  ay 
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1)  C6M  Functional  Spaclfication  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Bezier  curve  generalized  drawing 
primitive  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP) 
data  record (D) 


Items  for  Data  Record: 

Integer  IL  0 

Integer  RL  0 

Integer  SL  0 

Data  Record  Description: 

The  data  record  is  empty. 

2)  CO!  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string’s  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6XS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  of  GKS.  It  will  use  the 
polyline  attribute  set.  The  control  points  are  transformed  to  NDC 
and  the  Bezier  curve  through  those  points  is  then  drawn.  A 
functional  description  of  its  input  parameters  is: 


Name 

number  of  points 

Coordinate  System 

Values 

(4) 

Data  Type 

I 

Bezier  control 
points 

wc 

4xP 

GDP  identifier 

as  assigned 

N 

GDP  data  record: 

empty 

Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 

4)  GKS  FORTBAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs”  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GDpqrs (  N,  PXA,  PYA  ) 

Input  Parameters: 

INTEGER  N  number  of  points  (4) 

REAL  PXA(4)f  PYA (4)  Bezier  control  points 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  PaeJe  Data  Record  function  (GPREC)  : 

INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 


ISO  DIS  8651  GKS 


5)  Pascal  language  binding  (reference: 

Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape”  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 

NumPoints  ■  4; 

Points  :  GAPoint Array; 

GRGDPData  •  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  0;  (*  null  data  record*) 

END; 


6)  GKS  Ada  language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part 3:  Ada) 

Registered  GDP ' s  are  in  a  library  package  named  GKS_GDP .  GKS  Ada 
provides  a  data  type  package/  GKS__TYPES  which  provides  types 
declarations . 

The  binding  for  the  "procedure  BEZIER_CURVE"  form  (as  defined  in 
■  paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  GDP  is : 


— GDP  function  for  a  Bezier  curve 

— Data  type  GDP_  DATA_RECORD  is  defined  in  package  GKS_GDP . 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS  TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package''GKS_GDP  is 

type  BEZIER_POINTS  is  new  WC . POINT_ARRAY  (1..4); 
procedure  BEZIER_CURVE 

(BEZIER__CONTROL_POINTS  :in  BEZIER_POINTS; 

GDP  IDENTIFIER  : in  GDP  ID); 


— more  GDP  procedures  can  be  inserted  here 


end  GKS  GDP; 
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Proposal  Numbor:l41 


Oslo  of  Prasontatlon:  10  Aoiil  1987 


Class  of  Qraphical  Itsm: 


Spoclfle  Escaps  I  Function  Idsntifisr:  I  Conic  Are 


Dsacriptlon 


A  boundad  connactad  portion  of  a  parant  conic  curva  is  drawn  in  a  dsfinition  spacs  and  than  transformad  to  worid 
coordinatas  by  tha  currant  conic  arc  transformation  matrix.  Tha  Intandad  raalization  of  tNs  output  primitiva  is 
aquhralant  to  that  intandad  for  tha  Conic  Are  Entity  of  IGES  Varsion  3.0.  Saa  tha  attachad  shaats  for  a  dataiiad 
dascription. 


Additional  Commanis 


_  Justification  for  Inclusion 


Conic  arcs  ara  commoniy  found  in  proprialary  graphics  systsm.  Thay  ara  naadad  to  support  tha  requirements  of 
offica  document  and  anginaaring  drawing  exchange.  Tha  conic  arc  capabiiitias  proposed  hare  ara  adapted  from  the 
IGES  Varsion  3.0  specification. 


Raiationshlp  to  Standards 


1 )  ISO  7942  (GKS)  •  Specifies  a  registered  GOP  as  defined  in  5.3. 

2)  iSO  8632  (CGM)  •  Specifies  a  registered  GOP  as  defined  In  5.6.10. 

3) *  *ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  GOP.  (See  attached  sheets). 


*At  present  at  tha  stage  of  draft.  Tha  status  of  this  is  provisional  unit  until  this  standard  has  been  approved  by 
ISO  council. 
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D#aeripfcioni 


(Note:  The  following  description  is  adapted  from  the  IGES  3.0 
specification . ] 

A  conic  are  is  generated  which  is  defined  as  follows: 

A  conic  arc  is  a  bounded  connected  portion  of  a  parent  conic  curve 
which  consists  of  more  than  one  point.  The  parent  arc  is  either  an 
ellipser  a  parabola,  or  a  hyperbola.  The  conic  arc  is  defined  by  a 
start  point,  P,  an  end  point,  Q,  and  six  parameters,  A,B,C,D,E, 
and  F.  The  conic  arc.  Itself  is  defined  by  the  six  parameters  and 
the  following  equation: 

+  B*Xtyt  +D*Xt  +E*Yt  -t-F  •  0 

where  (Xf.,Y^)  is  an  abstract  Cartesian  coordinate  system  called 

"definition  space".  In  order  for  the  conic  arc  to  be  processed 
correctly  by  the  receiving  system  given  the  above  presentation,  the 
conic  arc  entity  must  be  positioned  such  that  each  of  its  axes  is 
parellel  to  either  the  Xf.  axis  or  axis.  The  arc  is  then 
positioned  correctly  in  the  appropriate  computer  graphics 
coordinate  system  by  using  the  value  of  the  current  Conic  Arc 
Transformation  Matrix. 

To  determine  the  form  of  the  conic  arc,  the  quantities  Ql,  Q2  and 
Q3  are  defined  as  follows: 

Ql  »  determinant  of  /  A  B/2  D/2  I 

I  B/2  C  E/2  I 
I  D/2  E/2  F  I 

Q2  -  determinant  of  I  A  B/2  I 

IB/2  Cl 

Q3  ~  A  +  C 

If  Q2>0  and  (Q1*Q3) <0,  then  arc  is  an  ellipse. 

If  Q2<0  and  QloO,  then  the  arc  is  a  hyperbola. 

If  Q2**0  and  QloO,  the  the  arc  is  a  parabola. 

In  the  case  where  the  conic  arc  is  elliptical,  to  distinquish  the 
arc  in  question  from  its  complement,  the  direction  of  the  arc  with 
respect  to  the  definition  space  must  be  from  start  point  to  end 
point  in  a  counterclockwise  direction. 

In  the  case  where  the  conic  arc  is  parabolic  or  hyperbolic,  the 
parameterization  defines  a  unique  portion  of  the  parabola  or  a 
unique  portion  of  a  branch  of  the  hyperbola,  thus,  the  direction  is 
irrelevant . 

The  direction  of  the  conic  arc  with  respect  to  the  space  where  it 
is  drawn  is  determined  by  the  original  direction  of  the  arc  in 
definition  space,  in  conjunction  with  the  action  of  the  current 
Conic  Arc  Transformation  Matrix. 
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Relationship  feo  parfelenlmr _ standards ; 


1)  C6M  ruaetloaal  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  start  and  end  points  are  in  definition  space  and  are  always 
encoded  as  real  numbers.  The  arc  is  transformed  to  VDC  using  the 
current  Conic  Arc  Transformation  Matrix  and  is  then  drawn.  A 
functional  description  of  the  conic  arc  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


point  list(nP)  -  none 
data  record  (D) : 

P 

Q 

A 

B 

C 

D 

E 

F 


Items  for  Data  Record: 


Integer  IL 

0 

Integer  RL 

10 

Real  RA(1) 

PX 

Real  RA(2) 

PY 

Real  RA(3) 

QX 

Real  RA(4) 

QY 

Real  RA(5) 

A 

Real  RA(6) 

B 

Real  RA(7) 

C 

Real  RA(8) 

D 

Real  RA(9) 

E 

Real  RA(IO) 

F 

Integer  SL 

0 

Data  Record  Description: 

The  data  record  contains  the  start  point  and  the  end  point  (in 
definition  space)  and  the  six  coefficients  of  the  defining 
equation. 
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2)  CGM  Sneodiags  (reference  ISO  8632  CGM;  Parts  2,2fA) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"/  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) / 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example/  in  the 
binary  encoding/  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6XS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  of  GKS.  It  will  use  the 
polyline  attribute  set.  The  arc  is  transformed  to  NDC  using  the 
current  Conic  Arc  Transformation  Matrix  and  then  drawn.  A 
functional  description  of  Its  input  parameters  is: 

Mama  Coordinate  System  Values 

number  of  points  (0) 


GPD  identifier  as  assigned 


GDP  data  record 

P (conic  arc  start  point): 

Q (conic  arc  end  point) : 

(conic  arc  coefficients) : 

A 

B 

C 

D 

E 

F 


Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  either  in  the  state 
f/SAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 


Data  Type 
I 


N 


2xR 

2xR 

R 

R 

R 

R 

R 

R 
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4)  OKS  rORTBAN  language  binding  (reference  ISO  DIS  86S1/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GDpqrs  (P,  Q,  A,  B,  C,  D,  E,  F) 

Input  Parameters : 

REAL  P(2)»  Q(2)  conic  arc  endpoints 

REAL  A,  Br  C,  D,  E,  F  conic  arc  coefficients 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Paclc  Data  Record  function  (GPREC)  : 


INTEGER  IL  0 

INTEGER  RL  10 

REAL  RA(  1  )  PX 

REAL  RA(  2  )  PY 

REAL  RA(  3  )  QX 

REAL  RA(  4  )  QY 

REAL  RA(  5  )  A 

REAL  RA(  6  )  B 

REAL  RA(  7  )  C 

REAL  RA(  8  )  D 

REAL  RA(  9  )  E 

REAL  RA(  10  )  F 

INTEGER  SL  0 


5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape”  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


NumPoints  -  0; 


GRGDPData  -  RECORD 

CASE  GOP Id  :  GTGDPDataTag  OF 


1:  ( 


StartX 

REAL; 

StartY 

REAL; 

EndX 

REAL; 

EndY 

REAL; 

CoefA 

REAL; 

CoefB 

REAL; 

CoefC 

REAL; 

CoefD 

REAL; 

CoefE 

REAL; 

CoefF 

REAL) 

END; 


50 


6)  acs  Ada  laaguag*  binding  (reference  ISO  DIS  8651/3  GKS 
Language  B indings ;  Par t 3 : Ada ) 

Registered  GDP's  are  In  a  library  package  named  GKS_GDP.  GKS  Ada 
provides  a  data  type  package/  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  CONIC_ARC"  form  (as  defined  In 
Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  GDP  Is : 


— GDP  function  for  a  conic  arc. 

— Data  type  GDP__DATA_RECORD  Is  defined  In  package  GKS__GDP. 

— GDP_ID  and  other  data  types  are  defined  In  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_GDP  Is 

type  CONIC_ARC_DATA_RECORD  is  new  GDP_DATA_RECORD  (0,10,0); 

procedure  CONIC_ARC 

GDP_IDENTIFIER  tin  GPD_ID; 

CONIC_ARC_RECORD  tin  CONIC_ARC_DATA_RECORD) ; 

— The  components  of  the  CONIC_ARC_DATA_RECORD  are  the  start  and  end 
— points  as  well  as  the  coefficients  specified  in  the  registration 
--procedure. 

— more  GDP  procedures  can  be  Inserted  here 
end  GKS  GDP; 
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Oat* *  of  Profontatlon:  1 10  AorU  1987 


SDonaorln 


Claas  of  Qraphleal  Itom:  ESCAPE 


Ifte  Eaeapo  I  Function  Idontiflor:  I  Sot  Conic  Are  Transformation  Matrix 


_  Ooaerlptlon 


This  ascapo  hmetlon  sots  a  valuo  Of  tho  transformation  matrix  noodad  to  doaeribo  howr  a  conic  are  doseribod  by 
tho  conic  are  GOP  is  movod  from  *dofinition  apaco”  to  world  eoortftnatos  (eaBad  'modal  spaca'  in  tha  IGES 
standard.)  it  Is  modailod  on  tha  Transformation  Matrix  Endty  of  iOES  Varsion  3.0.  Saa  attachad  shoots  for  a 
datailad  doseription. 


Additional  Commonts 


_  Justification  for  Inclusion 


Conic  ares  ara  commonly  found  in  propriatary  gr^)hics  systam.  Thoy  ara  noadad  to  support  tha  raquiramants  of 
anginaaring  drawing  axehanga.  Oua  to  various  numaricai  probiams,  such  curvas  ara  bast  spaciTiad  in  a  'dafinition 
spaca”  and  than  Iransformad  to  thair  final  location  by  applying  a  transformation  matrix.  This  ascapa  function  is 
naadad  to  supply  valuas  for  tha  raquirad  'modailing”  or  transformation  matrix.  Tho  capabiiitias  proposad  hara 
ara  adaptod  from  tha  IGES  Varsion  3.0  spodfication,  and  ara  spacilizod  to  tha  casa  of  two-dimansions. 


Ralatlonship  to  Standards 


1)  ISO  7942  (GKS)  -  Spadflas  a  ragfotarsd  GOP  as  dalinad  in  5.3. 

2)  ISO  8632  (CGM)  •  Spadfias  a  rogistarad  GOP  as  dafinad  in  5.6.10. 

*3)  ISO  8651  (GKS  Languaga  Bindings)  •  Spadfias  a  GOP.  Saa  attachad  shoals. 


*At  prasant  at  tha  staga  of  draft.  Tha  status  of  this  is  provisional  unit  until  tMs  standard  has  boon  approvad  by 
ISO  councU. 
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[Note:  This  escape  Is  adapted  from  the  Transformation  Matrix  Entity 
of  the  I6ES  version  3.0  specification.] 

This  escape  is  intended  to  work  in  conjunction  with  the  conic  arc 
generalized  drawing  primitive  to  transform  the  conic  arc  from 
definition  space  to  drawing  space.  The  conic  arc  transformation 
matrix  transforms  definition  space  point  coordinates  by  means  of 
a  matrix  multiplication.  This  transformation  is  performed  by 
applying  the  following  matrix  multiplication  to  coordinates: 

I  ^11  ^12  ^13  I  f  ^in  I  I  >fout  I 

I  R2i  R22  R23  I  X  I  Yin  I  -  /  J^out  / 

I  1  I 

where  l^ijl  is  the  transformation  matrix, 

corrdinate  to  be  transformed  and  (XQm:'^out^  coordinate 

resulting  from  the  transformation.  Both  the  input  and  output 
coordinate  systems  are  assumed  to  be  orthogonal,  Cartesian  and 
right-handed. 

[Note:  IGES  version  3.0  defines  this  transformation  as  a  matrix 
multiplication  followed  by  a  vector  addition  (translation) .  To  be 
consistent  with  the  way  transformations  are  defined  in  computer 
graphics  standards,  an  equivalent  homogeneous  coordinate 
formulation  is  used  here  instead.  To  translate  this  form  to  the 
IGES  form,  simply  use  the  first  two  columns  of  the  above  matrix  as 
the  IGES  matrix  and  the  last  column  as  the  "T-vector"  values  T1  and 
T2  in  IGES.] 


1)  C6M  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

This  matrix  is  used  to  transform  a  Conic  Arc  element  from  its 
definition  space  into  VDC  where  it  is  drawn.  A  functional 
description  of  the  Set  Conic  Arc  Transformation  Matrix  escape 
parameters  is: 

Parameters : 

function  Identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

Rll 

R12 

R13 

R2i 

R22 

R23 

Items  for  Data  Record: 


Integer  IL  0 

Integer  RL  6 

Real  RA(l)  Rll 

Real  RA(2>  Rl2 

Real  RA(3)  R13 

Real  RA(4)  R2i 

Real  RA(5)  R22 

Real  RA(6)  R23 

Integer  SL  0 


Data  Record  Description: 

The  parameters  define  a  2X3  matrix  used  to  transform  a  Conic 
Arc  element  from  its  definition  space  into  VDC  where  it  is  drawn. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3, A) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
records  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  .data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


3)  6KS  runetional  Description  (reference  ISO  7942  6KS 
functional  description) 

This  escape  is  applicable  at  level  Oa  of  6KS.  A  functional 
description  of  its  parameters  is  given  below: 


Marne  Values  Data  Type 

escape  function  identifier  as  assigned  N 

(transformation  matrix)  2X3XR 

Rll  R 

R12  R 

R13  R 

R21  R 

R22  R 

R23  R 


output  data  record: 
none 

Errors : 

5  GKS  not  In  proper  state:  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  poii  ts  is  invalid 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs(Rll,  R12,  R13r  R21,  R22,  R23) 

Input  Parameters : 

REAL  Rll  2X3  transformation  matrix 

REAL  R12 

REAL  R13 

REAL  R21 

REAL  R22 

REAL  R23 


Output  Parameters : 
NONE 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


INTEGER  IL  0 

INTEGER  RL  6 

REAL  RA(  1  )  Rll 

REAL  RA(  2  )  R12 

REAL  RA(  3  )  R13 

REAL  RA(  4  )  R21 

REAL  RA(  5  )  R22 

REAL  RA(  6  )  R23 

INTEGER  SL  0 


Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 


5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  ”1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GREscapeDataIn  »  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 
1:  ( 

MatrixRealll  :  REAL; 
MatrlxReall2  :  REAL; 
MatrlxReall3  :  REAL; 
MatrixReal21  :  REAL; 
MatrixReal22  :  REAL; 
MatrixReal23  :  REAL) ; 

END; 


GREscapeDataOut  »  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*  Null  Record*) 

END; 


6)  GXS  Ada  Laagoaga  blading  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS  ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_CONIC_ARC_TRANSFORMATION_ 
MATRIX"  form  (as  defined  In  Paragraph  4.1  of  the  GKS  Ada  language 
binding)  of  the  ESCAPE  Is: 


— Escape  function  for  a  set  conic  arc  transformation. 

—Data  type  ESCAPE_ID  and  E''>CAPE_FLOAT  are  defined  in  package 
— GKS_ESCAPE . 

— Other  data  types  are  defined  In  package  GKS_TYPES. 


with  GKS  TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  CONIC_TRANSFORM_MATRIX  is  array  (1..2,1..3)  of  ESCAPE_FLOAT; 

procedure  SET_CONIC_ARC_TRANSFORMATION_MATRIX 
(ESCAPE_IDENTIFIER  :in  ESCAPE_ID; 

CONIC__ARC_MATRIX  :  in  CONIC_TRANSFORM_MATRIX  )  ; 

— The  components  of  CONIC_ARC_DATA  are  the  2X3  transformation 
— matrix  specified  in  the  registration  proposal 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Proposal  Numbtr;  1 43 


Date  of  Presentation:  1 10  April  1987 


Sponsorlno  Authority:  I  ANSI 


Class  of  Graphical  Item:  I  GOP 


GDP  Identifier:  I  Parametric  Spline  Curve 


Description 


A  planar  (two  dimensional)  parametric  spline  curve  is  drawn.  The  intended  realization  of  this  output  primitivs  is 
equivalent  to  that  intended  (or  the  Parametric  Spline  Curve  Entitty  of  IGES  Version  3.0,  with  the  restriction  that 
the *  *Z  polynomial”  of  the  IGES  standard  be  zero.  See  attached  sheets  (or  a  detailed  description. 


Additional  Comments 


Justification  for  Inclusion 


Parametrics  spline  curves  are  commonly  found  in  proprietary  graphics  system.  They  are  needed  to  support  the 
requirements  of  engineering  drawing  exchange.  The  capabilities  proposed  here  are  adapted  from  the  IGES  Version 
3.0  specification,  and  are  specilized  to  the  case  of  two-dimensions. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

*3)  ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP.  (See  attached  sheets). 


*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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A  paraaatzlc  splln*  eurv«  as  defined  below  is  drawn.  A 
parametric  spline  curve  Is  a  sequence  of  parametric  polynomial 
segments.  The  curve  Is  defined  using  the  following  parameters: 

curve  type  (E) 

H  (degree  of  continuity)  (I) 

(number  of  segments)  (I) 

T  (brealc  point  list  for  polynomial)  ((N+1)R) 

X  coordinate  polynomial  list  (H  sets  of  four) 

AxfBx^Cx^Dx  ((4*N)R) 

Y  coordinate  polynomial  list  (N  sets  of  four) 

Ay,By,Cy,Dy  ((4*N)R). 

This  parameterization  is  generalized  to  allow  for  the 
representation  of  many  different  parametric  spline  curves  using 
this  one  element.  The  curve  type  parameter  indicates  the  type  of 
parametric  curve  as  it  was  represented  in  the  sending  system  before 
being  converted  to  this  generic  form.  The  following  curve  types 
have  been  assigned: 

1)  linear 

2)  quadratic- 

3)  cubic 

4)  Wilson-Fowler 

5)  modified  Wilson-Fowler 

6)  B  spline 

Additional  curve  types  are  reserved  for  future  registration  and 
standardization. 

The  degree  of  continuity  parameter,  H  indicates  the  smoothness,  or 
continuity  of  the  curve  with  respect  to  arc  length.  If  H^O,  the 
curve  is  continuous  at  all  brealt  points.  If  H-1,  the  curve  is 
continuous  and  has  slope  continuity  at  all  break  points.  If  H*2, 
the  curve  is  continuous  and  has  both  slope  and  curvature  continuity 
at  all  break  points. 

The  number  of  segment  parameters,  N,  is  the  number  of  polynomial 
segments  to  be  used  to  define  the  curve.  Each  segment  is  defined  by 
a  cubic  polynomial  in  X  and  Y  that  is  evaluated  using  the  eight 
polynomial  coefficients  associated  with  that  segment: 
A xr  ^ xf  ^ X' ^ X' ^ ^ y>  ^ y  ’  Segment  1  is  delimited  by  its 
breakpoints,  T(i)  and  T(i+1)  . 
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The  coordinates  of  the  points  of  the  1^^  segment  of  the  curve  are 
given  by  the  following  cubic  polynomial  equations.  Note  that 
coefficients  Dr  or  C  and  D  will  be  zero  if  the  polynomials  are  of 
degrees  2  or  1,  respectively: 

X(u)  -  Ajtd)  +  Bx(i)*s  +  Cx<i)*s2  *  Dx(i)*s^ 

Y(U)  •  Ay  a )  +  By(i)*S  +  Cya)*s2  +  Dy(i)*S^ 

where  T(i)  <*  u  <»  T(i+1)  .  .,tf  and  s  ■  u  -  T(i} .  In  order  to 

avoid  degeneracyf  for  each  i  at  least  one  of  the  six  real 
coefficients  BxfCxfDxfBy,Cy,Dy  must  be  non-zero. 

To  enable  determination  of  the  terminate  point  and  derivatives 
without  computing  the  polynomials,  the  polynomials  and 

derivatives  are  evaluated  at  u  «  Tdr-t-l) .  These  data,  divided  by  the 
appropriate  factorial  (i.e.  the  second  derivative  divided  by  2!, 
the  third  by  J.',  etc.),  are  used  as  the  or  terminate  point 

values . 

Relationship  to _ partiCttlax _ standards : 

1)  C6M  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  parameters  of  the  curve  are  transformed  to  VDC  and  the  curve  is 
drawn.  A  functional  description  of  the  parametric  spline  curve 
parameters  is : 

Parameters: 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list  -  empty 
data  record  (D) :  - 

C  (curve  type)  (Note  1)  (E) 

H  (degree  of  continuity)  (I) 

N  (number  of  segments)  (I) 

T  (break  point  list  for  polynomial)  ((N+1)R) 

X  coordinate  polynomial  list  (N  sets  of  four) 

AX, BX,CX,DX  ((4*N)R) 

Y  coordinate  polynomial  list  (N  sets  of  four) 

AY, BY,CY,DY  ((4*N)R). 

Note  1:  Curve  type  is  one  of  (linear,  quadratic,  cubic, 
Wilson-Fowler,  modified  Wilson-Fowler,  B  spline) 
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Items  for  Data  Record: 


Integer  IL 

3 

Integer  IA(1) 

C 

Integer  IA(2) 

H 

Integer  IA(3) 

N 

Integer  RL 

(9N+1)R 

Real  RA(1) 

T(l) 

•  «  « 

Real  RA(N-t-l) 

T(N+1) 

Real  RA(N+2) 

AX{1) 

Real  RA(N+3) 

BX{1) 

Real  RA(N-i-4) 

CX{1) 

Real  RA(N-«>5) 

DX(1) 

Real  RA(N-»-6) 

AX(2) 

Real  RA(N+7) 

BX(2) 

Real  RA(5N+2) 

AY(1) 

Real  RA(5N-t-3) 

BY(1) 

•  •  •  • 

Integer  SL 

0 

Data  Record  Description: 

The  data  record  contains  the  parameters  needed  to  define  the 
parametric  spline  curve:  curve  type,  degree  of  continuity,  number 
of  segments,  break  point  list,  and  the  coefficients  of  the  two 
polynomials  that  define  the  X  and  Y  coordinate  values, 
respectively,  for  the  curve. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GKS  Functional  Specification 

FunctioAal  Description) 

(reference  ISO 

7942  GKS 

This  GDP  is  applicable  at  level  Oa  of  GKS.  It  will  use  the 

polyline  attribute  set.  The  parameters  of  the  curve  are 

transformed  toi  NDC  and  the  curve  is  drawn.  A  functional 

description  of  its  input  parameters  is: 

Name  Coordinate  System 

number  of  points 

Values 

(0) 

Data  Type 
I 

GDP  identifier 

as  assigned 

N 

GDP  data  record: 

see  IGES  attachments  for  definitions 

CTYPE 

Note  1 

I 

H 

(0,1,2) 

I 

NSEG 

I 

breakpoints, 

"T"  values 

(N+DR 

X  coordinate  polynomial 
coefficients 

((4*N)R) 

Y  coordinate  polynomial 
coefficients 

((4*N)R)  . 

Not*  1:  Curve  type  is  one  of  (linear^  quadratiCr  cubiCf 
Wllson-Fowlerr  modified  Wllson-Fowler^  B  spline) 


Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registraton  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 


SUBROUTINE  GDpqrs (  CTYPE,  H,  NSEG,  T,  X,  Y  ) 


Input  Parameters: 
INTEGER  CTYPE 
INTEGER  H 
INTEGER  NSEG 
REAL  T(NSEG+1) 
REAL  X (NSEG, 4) 
REAL  Y (NSEG, 4) 


type  of  spline  curve 
degree  of  continuity 
number  of  polynomial  segments 
break  point  list 

X  coordinate  polynomial  coefficients 
Y  coordinate  polynomial  coefficients 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


Integer  IL 

3 

Integer  IA(1) 

C 

Integer  IA(2) 

H 

Integer  IA(3) 

N 

Integer  RL 

(9N+1)R 

Real  RA(1) 

T(l) 

«  •  • 

Real  RACN-i-l) 

T(N+1) 

Real  RA(N-t-2) 

AX(1) 

Real  RA(N+3) 

BX{1) 

Real  RA(N'l-4) 

CX(1) 

Real  RA(N+5) 

DX(1) 

Real  RA(N+6) 

AX(2) 

Real  RA(N+7) 

BX(2) 

•  ■  •  • 

Real  RA(5N-i'2) 

AY(1) 

Real  RA(5N-'-3) 

BY(1) 

•  •  •  • 

Integer  SL 

0 

5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEGDPCurvePropertyS  »  (  linear^  quadratic,  cubic, 

Wilson-Fowler,  modified  Wilson-Fowler, 
B  spline) ; 


GRGDPData  -  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ( 

CType  :  GEGDPCurvePropertyS; 

H  :  INTEGER; 

NSeg  :  INTEGER; 

T  :  array  [1 . .  (NSeg+1) ]  of  REAL; 

X  ;  array  [1 . . (4*NSeg) j  of  REAL; 

Y  :  array  (1 . . (4*NSeg) ]  of  REAL) ; 

END; 
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6)  6X3  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 

Language  Bindings;  Part 3:  Ada) 

Registered  GDP's  are  In  a  library  package  named  GKS_GDP.  GKS  Ada 
provides  a  data  type  package »  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  PARAMETRIC_SPLINE_CURVE"  form  (as 
defined  In  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the 
GDP  Is: 


— GDP  function  for  a  parametric  spline  curve  gap. 

— Data  type  (9DP_pATA__REC0RD  la  defined  In  package  GKS_GDP. 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS__TYPES/ 
use  GKS__TYPES; 
package  GKS_GDP  Is 

type  CURVE_TYPE  is  (linear/  quadratic^  cublC/  Wilson-Fowler, 
modified  Wllson-Fowler/  B  spline); 
type  DEGREE_OF_CONTINUITY  is  new  INTEGER  range  0..2; 
type  BREAKPOINT_ARRAY  is  array  (SMALL. NATURAL  rangeO)  of 
ESCAPE_FLOAT; 

type  SPLINE__CURVE_DATA_RECORD  (NOM_SEG  :  SMALL__NATURAL  0)  is 
record 


SPLINE_TYPE 
CONTINUITY 
BREAKPOINTS 
POLYNOMIALS 
end  record; 


CURVE_TYPE; 

DEGREE_OF  CONTINUITY; 

BREAKPOINT  ARRAY  (1 .  .  (NUM  SEG4-1)  )  ; 
polynomial”* array  ( 1 .  . NUM  SEG/ 1 .  .  4 )  ; 


procedure  PARAMETRIC  SPLINE  CURVE 

(GDP  IDENTIFIER  “  “  tin  GDP_ID; 

SP LINE_CURVE_RECORD  tin  SP L INE_CURVE_D ATA_RECORD ) ; 

— The  components  of  the  SPLINE_CDRVE_DATA_RECORD  are  those 
— specified  In  the  registration  proposal. 

— more  GDP  procedures  can  be  inserted  here 

end  GKS  GDP; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Rtlattonship  to  Standards 

1)  ISO  7942  (GKS)  •  Spectfias  a  registered  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  GDP  as  defined  in  5.6.10. 

*3)  ISO  8651  (GKS  Language  BirKfings)  •  Specifies  a  registered  GDP.  (See  attached  sheets). 


‘At  present  at  the  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaeriptelont 

A  raitlonal  B>splin«  eiaxv«  as  defined  below  is  drawn.  The  curve 
Is  defined  using  the  following  parameters: 

K  (upper  Index  of  summation)  (I) 

M  (degree  of  the  basis  functions)  (I) 
curvejopen  flag  (one  of:  open,  closed)  (E) 
equatTon_type  flag  (one  of:  rational,  polynomial)  (E) 
periodic  flag  (one  of:  non-periodic,  periodic)  (E) 

T  (knot  sequence)  ( (K-fM-t-DR) 
w  (weights)  ((K+1)R) 

P  (control  points)  ((K4>l)P) 
start^param  ,end_param  (2R) 


The  parametric  equation  governing  the  definition  of  the  rational 
B-spline  curve  Is  shown  In  the  following  expression: 


G<t) 


W(i)p(i)b^(t) 


i»0 


^W(i)b^(t) 


i-o 


where  W(i)  are  the  weights#  P(i)  are  the  control  points  and  b^  are 
the  basis  functions. 

The  B-spllne  basis  functions#  bi^  are  all  non-negative  piecewise 
polynomials  of  degree  N.  T  Is  a  non-decreasing  sequence  of  real 
numbers  T(-M) ,  . .  .,T(0} ,  .  .  Each  function  bj  is  supported  by 

the  knot  sequence  Interval  [T(i-M)  #T(l-fl)  ]  .  Between  any  two 
adjacent  knot  values#  T(j)  and  T(j'*-1)#  the  corresponding  basis 
function  can  be  expressed  as  a  single  polynomial  of  degree  M. 

The  curve  Itself  Is  parameterized  where: 

start jparam  <—  t  <*•  end _j>aram, 

T(0)  <  start _param  <  end jparam  <»  T(N) 

Thus#  for  any  parameter  value  t  between  T(0)  and  T(K+1),  the  sum  of 
the  basis  functions  satisfies  the  following  Identity: 


ft;  -  1. 

1-0 

If  the  beginning  and  ending  points  of  the  curve  are  identical#  then 
the  curve__open  flag  is  set  to  closed,  otherwise#  it  is  set  to  open. 

If  all  of  the  weights#  W,  are  not  equal#  then  the  equation_type 
flag  is  set  to  rational.  Otherwise#  if  all  of  the  weights  are 
equal#  then  all  of  the  weights  cancel#  the  denominators  sum  to  one 
and  the  equation_type  becomes  polynomial. 
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Ralationahlo _ tfi _ nagfeienlag  gtandardi 

1)  CGM  Functional  Spaeification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  parameters  of  the  curve  are  transformed  to  VDC  and  the  curve  is 
then  drawn.  A  functional  description  of  the  rational  B-spline 
parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  llst(nP)  -  contains  the  control  points 
data  record  (D) : 

K  (upper  index  of  sum)  (I) 

M  (degree  of  the  basic  functions)  (I) 
curve_open  flag  (one  of:  open^  closed)  (E) 
equation__type  flag  (one  of:  rational,  polynomial  (E) 
periodic  flag  (one  of:  non-periodic,  periodic)  (E) 

T  (knot  sequence)  ((K+M+i)R) 

W  (weights)  ((K+1)R) 

P  (control  points)  ((K+1)P) 
start_param  ,endjparam  (2R) 


Items  for  Data  Record: 


Integer  IL 

5 

Integer  IA(1) 

K 

Integer  IA(2) 

M 

Integer  IA(3) 

curve^open  flag 

Integer  IA(4) 

equatTon_type  flag 

Integer  IA(5) 

periodic  flag 

Integer  RL 

2K  +  M  +  4 

Real  RA(1) 

T(-M) 

Real  RA(2) 

T(-M+l) 

•  •  •  « 

Real  RA(K-t-M+l) 

T(K+1) 

Real  RA(K-«-M't>2) 

W(0) 

•  «  •  « 

Real  RA(2K'«'M-»-2) 

W(K+1) 

Real  RA(2K+M+3) 

startjjaram 

Real  RA(2K+M+4) 

end_param 

Integer  SL 

0 

Data  Record  Description: 

The  data  record  contains  the  parameters  that  define  the 
rational  B-spline  curve:  the  upper  index  of  summation,  the  basis 
functions,  the  curve__open  flag,  the  equat  ion_type  flag,  the 
periodic  flag,  the  knot  sequence,  the  weights,  and  two  parameters 
—  start_param  and  end_param  —  that  determine  the  beginning  and 
end  of  the  curve. 
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2)  CGM  Eneodinga  (reference  ISO  8632  CGM;  Parts  2,3,  i) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record#  containing  the  data  record  items  in  sequential  order  from 
first  to  last#  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"#  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is#  the  data  record  items)# 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example#  in  the 
binary  encoding#  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents#  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6X3  Functional  Specification  (reference  ISO  7942  6KS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  of  GKS.  It  will  use  the 
polyline  attribute  set.  The  control  points  are  transformed  to  NDC 
and  the  curve  is  drawn.  A  functional  description  of  its  input 
parameters  is: 


Name 

Coordinate 

System  Values  Data  Type 

number  of  points 

I 

control  points 

WC 

nxP 

GDP  identifier 

as  assigned  N 

GDP  data  record: 

K  (upper  index  of 

summation) 

I 

M  (degree  of  basis 

functions) 

I 

COFLAG 

(open# closed)  E 

ETFLAG 

(rational# polynomial)  E 

PFLAG 

• 

(non-periodic# periodic) E 

T 

R 

W 

R 

SPARAM#  EPARAM 

R 

Errors : 

5  GKS  not  in  proper  state:  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Number  of  points  is  invalid 
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4)  6XS  FORTRAN  languag*  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 


a)  The  following  language  binding  is  proposed  for  the  "GDpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 


SUBROUTINE  GDpqrs (  N,  PXA,  PYA,  K,  M,  COFLAG,  ETFLAG,  PFLAG,  T, 

H,  SPARAM,  EPARAM) 


Input  Parameters : 
INTEGER  N  , 

REAL  PXA(*),  PYA(*) 
INTEGER  K 
INTEGER  M 
INTEGER  COFLAG 
INTEGER  ETFLAG 
INTEGER  PFLAG 
REAL  T(  N+2M  ) 

REAL  W(  K  ) 

REAL  SP ARAM, EPARAM 


number  of  control  points 
control  points 
upper  index  of  summation 
degree  of  basis  functions 


knot  sequence 
weight 

determine  start  and  end  points 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


Integer  IL 

5 

Integer  IA(1) 

K 

Integer  IA(2) 

M 

Integer  IA(3) 

COFLAG 

Integer  IA(4) 

ETFLAG 

Integer  ■IA(5) 

PFLAG 

Integer  RL 

2K  +  M  +  4 

Real  RA(1) 

T(-M) 

Real  RA(2) 

T(-M+l) 

•  •  •  • 

Real  RA(K+M+1) 

T(K+1) 

Real  RA{K+M+2) 

W(0) 

Real  RA(2K+M+2) 

W(K+1) 

Real  RA(2K+M+3) 

SPARAM 

Real  RA(2K+M+4) 

EPARAM 

Integer  SL 

0 
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5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEGDPCurveProperty2  ■  (GVGOPOpen^  GVGDPClosed) ; 
GEGDPCurveProperty3  •  (GVGOPRatlonal/  GVGDPPolynomical) ; 
GEGDPCurveProperty4  «  ((aVGDPNonPeriodic,  GDPPerlodic) ; 

Points  :  GAPoint Array;  (*control  points*) 

GRGDPData  -  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ( 

K  :  INTEGER; 

M  :  INTEGER; 

CurveOpenFlag  :  GEGDPCurveProperty2 ; 

EquationTypeFlag  :  GEGDPCurveProperty3; 

PeriodicFlag  :  GEGDPCurveProperty4 ; 

T  :  REAL; 

W  :  REAL; 

StartParam  :  REAL; 

EndParam  :  REAL;) 

END; 
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6)  6KS  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

a)  Registered  GDP's  are  in  a  library  package  named  GKS_GDP.  GKS 
Ada  provides  a  data  type  package^  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  Rational_B_SPLINE_CURVE"  form 
(as  defined  in  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of 
the  GDP  is: 


— GDP  function  for  a  rational  B__Spllne  curve. 

— Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_GDP. 

— GDP_ID  and  other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS-TYPES; 
use  GKS-TYPES; 
package  GKS_GDP  is 

type  CURVE_OPEN_TYPE  is  (OPEN,  CLOSED) ; 

CURVE__OPEN_VALOE  ;  in  CURVE_OPEN_TYPE; 

type  EQUATION_TYPE  is  (RATIONAL,  POLYNOMIAL) ; 

EQUATION__VALUE  :  in  EQUATION_TYPE; 

type  PERIODIC  TYPE  is  (NON-PERIODIC,  PERIODIC) ; 

PERIOD  IC__VALyE  :  in  PERIOD  IC_TYPE; 

type  KNOT__SEQUENCE_ARRAY  is  array  (SMALL  NATURAL  tangeo)  of 
ESCAPE  FLOAT; 


type  WEIGHT_SEQUENCE_ARRAY  is  array  (SMALL  NATURAL  rangeo)  of 
ESCAPE  FLOAT; 


type  RATIONAL__B_SPLINE_DATA_RECORD  is 
record 


UPPER_INDEX_OF_SUM 
DEGREE_OF_BAS IS_FUNCTIONS 
CURVE_OPEN_VALUE 
EQUATION_VALUE 
PERIODIC_VALUE 
KNOT_SEQUENCE 
WEIGHT_SEQUENCE 
START_PARAM 
END_PARAM 
end  record; 


INTEGER; 

INTEGER; 

CURVE_OPEN_TYPE ; 
EQUATION_TYPE; 
PERIODIC_TYPE; 
KNOT_SEQUENCE_ARRAY ; 

WE I GHT_SEQUENCE_ARR A Y ; 
ESCAPE_FLOAT; 

ESCAPE  FLOAT; 


procedure  RATIONAL_B_SPLINE__CURVE 
(CONTROL_POINTS 
GDP_IDENTIFIER 

RATIONAL  B  SPLINE  DATA  RECORD 


:in  WC.POINT_ARRAY; 

tin  GDP_ID; 

tin  GDP  DATA  RECORD) ; 


— The  components  of  the  RATIONAL_B_SPLINE_DATA_RECORD  are  those 
— specified  in  the  registration  proposal. 

— more  GDP  procedures  can  be  inserted  here 


end  GKS  GDP; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


I  Proposal  Number:! 


Date  of  Prosontatlon:  1 10  April  1987 


SDonsorIn 


mmm 


Class  of  Graphical  Ham:  I  ESCAPE 


Soaclfle  Eacaps  I  Function  Identifier:  I  Set  Edqe  Mitre  Limit 


Description  _  _ 


This  escape  function  sets  a  value  (or  the  current  edge  mitre  limit.  This  value  helps  determine  the  shape  put  at 
comers  between  portions  of  edges  during  subsequent  Interpretation  of  filled  area  graphical  primitives.  Its 
purpose  is  to  place  a  limit  on  how  long  a  ‘spike* *  can  emanate  from  the  join  of  two  portions  of  an  edge  of  a  filled 
area  primitive  by  ‘truncating*  long  mitre  joins  into  bevel  joins.  See  attached  sheets  (or  additional  details. 


Additional  Comments 


None. 


Justification  for  Inclusion _ 

User  specified  mitre  limits  are  commonly  found  in  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing.  The  edgetype  capabilities  proposed  here  are  adapted 
from  those  in  the  PostScript-  language,  which  was  developed  by  Adobe  Systems  Incorporated,  and  whose 
specification  has  been  placed  in  the  public  domain. 


Relationship  to  Standards  _ 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

‘At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Daaeription; 

Sat  Edga  Mitr«  Limit  sets  the  current  edge  mitre  limit  value  in 
the  graphics  state  to  mitre  length  specifier,  which  must  be  a 
number  greater  than  or  equal  to  1.  Mitre  limit  is  a  dimensionless 
number  that  controls  the  treatment  of  corners  between  portions  of 
the  edges  of  filled  area  output  primitives  when  mitre  joins  have 
been  specified  (see  Set  Line  Join)  .  (Set  Line  Mitre  Limit  and 
Set  Line  Join  provide  similar  capabilities  for  the  edges  of  line 
and  curve  primitives. )  When  portions  connect  at  a  sharp  angle,  a 
mitre  join  results  in  a  spike  that  extends  well  beyond  the 
connection  point.  The  purpose  of  the  mitre  limit  is  to  cut  off  such 
spikes  when  when  they  become  objectionably  long. 

At  any  given  corner,  the  mitre  length  is  the  distance  from  the 
point  at  which  the  inner  edges  of  the  curve  or  line  portions 
intersect  to  the  point  in  which  the  outside  edges  of  the  portions 
intersect  (i.e.,  the  diagonal  length  of  the  mitre).  This  distance 
increases  as  the  angle  between  the  portions  decreases.  Whenever  the 
ratio  of  the  mitre  length  to  the  edge  width  exceeds  the  edge  mitre 
limit  parameter  and  is  also  greater  than  1.415,  a  bevel  is 
introduced  at  the  join  perpendicular  to  the  angle  bisector  and  at 
the  mitre  limit.  (Note  that  this  is  not,  in  general  equivalent  to 
introducing  a  bevel  join  when  this  limit  is  reached.  Introducing 
such  a  join  causes  discontinous  behaviour,  where  small  changes  in 
the  angle  between  the  segments  results  in  radically  different 
appearances.)  Whenever  the  ratio  of  the  edge  mitre  length  to  the 
edge  width  exceeds  the  edge  mitre  limit  parameter  and  is  also  less 
than  or  equal  to  1.415  (that  is,  when  the  edge  mitre  limit 
parameter  is  between  1  and  1.415  inclusive),  a  bevel  join  is 
implemented  at  the  mitre  limit. 

The  ratio  of  edge  mitre  length  to  edge  width  is  directly  related  to 
the  angle  between  the  segments  by  the  formula: 

mitre  length  /  edge  width  •  1  /  sin  (<(f/2) 

Examples  of  edge  mitre  limit  values  are:  1.415  cuts  off  miters 
(converts  them  to  bevels)  at  angles  less  than  90  degrees,  2.0  cuts 
off  miters  at  angles  less  than  60  degrees,  and  10.0  cuts  miters  off 
at  angles  less  than  11  degrees.  The  default  value  of  edge  mitre 
limit  is  10.  Setting  the  edge  mitre  limit  to  1  cuts  off  miters  at 
all  angles  so  that  bevels  are  always  produced  even  when  miters  are 
specified.  The  lengths  in  the  above  formula  must  be  in  the  same 
units  (WC,  VDC,  etc.)  and  cancel  out  to  yield  a  dimensionless  edge 
mitre  limit  value.  Edge  mitre  limit  applies  to  the  edges  of  filled 
area  primitives 
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1)  cot  runetlonal  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Deacrlptlon) 

A  functional  description  of  the  Set  Edge  Mitre  Limit  escape 
parameters  is: 

Parameters : 

function  identifier 


data  record  (D) : 
mitre  length  (R) 

Items  for  Data  Record: 

Integer  IL 
Integer  RL 
Real  RA(1) 

Integer  SL 

Data  Record  Description: 

The  parameter  defines  the  edge  mitre  length. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3^4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record#  containing  the  data  record  items  in  sequential  order  from 
first  to  last#  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"#  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is#  the  data  record  items) # 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding#  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents#  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


(I)  as  assigned  by  the  Registration 
Authority 


0 

1 

mitre  length 
0 
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3)  6KS  Functional  Oaaexiptlon  (reference  ISO  7942  GKS 
functional  description) 

This  escape  is  applicable  at  level  Oa  of  GKS.  A  functional 
description  of  its  parameters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

mitre  length  r 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (MITRE) 

Input  Parameters: 

REAL  MITRE  mitre  length 

Output  Parameters : 

NONE 


% 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  0 

INTEGER  RL  1 

REAL  RA(  1  )  mitre  length 

INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 

5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GESCAPE"  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GREscapeOataIn  *  Record 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

MltreLength  :  REAL  ) ; 

END; 

GREscapeDataOut  •  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 

1:  0  ;  (*Null  Record  *) 

END; 
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6)  GXS  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package/  GKS_TypES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET__EDGE_MITRE_LIMIT"  form  (as 
defined  In  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  Is : 


— Escape  function  for  a  set  edge  mitre  limit. 

— Data  types  ESCAPE_ID  and  ESCAPE  FLOAT  are  defined  In  package  GKS 
— GKS_ESCAPE .  ~ 

— Other  data  types  are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS__TYPES; 
package  GKS_ESCAPE  is 

MITRE_LENGTH  : in  ESCAPE_FLOAT; 

procedure  SET_EDGE__MITRE_LIMIT 

(ESCAPE_IDENTIFIER  : in  ESCAPE_ID; 
MITRE  LIMIT  ; in  MITRE  LENGTH; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 


77 


.  PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


lDit«  of  PfMnftlon;  IIP  April  1987  I 

1  Sponsoring  Authority:  t  ANSI  I 

I  Cl«s>  of  Qnphicil  Itam;  I  BCAPE  I 

isptcific  E«c«p«  I  Function  lcfntlll>r;  ISetEdcwCao  I 

I  Dfcriptlon  1 


This  Mcapp  function  Mts  a  valua  for  tha  currant  adga  cap.  Thia  valua  ia  to  datarmina  tha  ahapa  put  at  tha  anda 
of  portiona  of  adgaa  during  aubaaquant  intarpratation  of  fillad  araa  graphical  primitivoa  .  Saa  attaehad  ahaat  for 
additional  dataila. 


Additional  Commanta 
Nona. 


Juatificatlon  for  Inclualon 

Uaar  apacifiad  adga  capa  ara  commonly  found  in  propriatary  graphica  ayatama.  They  ara  naadad  to  support  tha 
raquiramants  of  offica  document  exchange  and  pubNahing.  Tha  adgatypa  capabilities  proposed  here  ara  adapted 
from  those  in  tha  PostScript  language,  which  was  davaiopad  by  Adobe  Systems  Incorporated,  and  whose 
specification  has  bean  placed  in  tha  public  domain. 


Ralatlonahip  to  Standards  _ 

1)  ISO  7942  (GKS)  •  Spactfias  a  ragistarad  escape  as  defined  in  5.2. 

2)  ISO  8632  (C6M)  -  Specifies  a  ragistarad  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  ragistarad  escape. 

*At  present  at  tha  stage  of  draft.  Tha  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaeription: 

S«t  Edga  Cap  sets  the  current  edge  cap  value  In  the  graphics 
state  to  the  value  specified  by  the  edge  cap  indicator.  This 
establishes  the  shape  to  be  put  at  the  ends  of  edge  elements  of 
filled  primitives.  The  following  edge  cap  values  are  supported: 

butt  cap  :  the  edge  Is  squared  off  at  the  endpoint;  there  Is 
no  projection  beyond  the  endpoint. 

round  cap  :  a  semicircular  arc  with  diameter  equal  to  the 
line  width  Is  drawn  around  the  endpoint  and  filled.  The 
drawn  edge  thus  projects  beyond  the  endpoint. 

projecting  square  cap  :  the  edge  Is  squared  off  at  a 
distance  equal  to  half  the  line  width  beyond  the  endpoint . 

Other  values  are  reserved  for  future  registration  and 
standardization.  The  default  value  Is  butt  cap. 

Relationship  to _ particular _ atandarda ; 


1)  C6M  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Edge  Cap  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

edge  cap  indicator  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

edge  cap  indicator 
0 
0 


The  parameter  defines  the  edge  cap  Index. 
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2)  COM  encodings  (reference  ISO  8632  CGM;  Parts  2,3/4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 

'  the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6KS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 

description  of  its  parameters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 

input  data  record: 

edge  cap  indicator  (BUTT,  ROUND,  £ 

PROJECTING  SQUARE) 

output  data  record: 
hone 

Errors: 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (EDCAP) 

Input  Parameters: 

INTEGER  EDCAP  edge  cap  indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 

Output  Parameters: 

NONE 
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b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  edge  cap  Indicator  (BUTT,  ROUND, 

PROJECTING  SQUARE) 

INTEGER  RL  0 
INTEGER  SL  0 

Output-  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 


5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE”  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  ”1”  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GEscapeEdgeEndType  «  (GVEscapeButt,  GVEscapeRound, 

GVEscapePro jectlngSquare) ; 

GREscapeDataln  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1;  ( 

EdgeCap  :  GEscapeEdgeEndType) ; 

End; 

GREscapeDataOut  -  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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S)  6KS  Adm  languag*  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part 3: Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package#  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET__EDGE  CAP"  form  (as  defined  in 
Paragraph  4.1  of  the  GKS  Ada  language  bXndlng)  of  the  ESCAPE  is: 


— Escape  function  for  a  set  line.  cap. 

-'Data  type  ESCAPE  ID  Is  defined  In  package  GKS_ESCAPE. 
— Other  data  types  are  defined  In  package  GKS_TYPES. 


with  GKS__TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  Is 

type  EDGE__CAP_INDICATOR_TYPE  is  (BOTT,  ROUND,  PROJECTING  SQUARE)  ; 
EDGE_CAP_INDICATOR__VALUE  :in  EDGE_CAP_INDICATOR_TYPE; 

procedure  SET_EDGE_CAP 

(ESCAPE_IDENTIFIER  :in  ESCAPE_ID: 

EDGE  CAP  INDICATOR  VALUE  :in  EDGE  CAP  INDICATOR  TYPE); 


— more  ESCAPE  procedures  can  be  Inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Proposal  NuwbTn 


Data  of  Prasontatlon:  1 10  Aoril  1987 


Sponsorin 


mmmrmy 


Class  of  Graphical  Hem:  I  ESCAPE  


Specific  Escape  I  Function  Identifier:  I  Set  Edge  Jotn 


Description _ 


This  escape  function  sets  a  value  for  the  cunent  edge  join.  This  vaiue  is  to  determine  the  shape  put  at  comers 
between  portions  of  edges  during  subsequent  Interpretation  of  filled  area  graphical  primitives.  See  attached 
sheet  for  additional  details. 


Additional  Comments 


None. 


Justification  for  inclusion _ 


User  specified  edge  joins  are  commonly  found  In  proprietary  graphics  systems.  They  are  needed  to  support  the 
requirements  of  office  document  exchange  and  publishing.  The  edge  capabilities  proposed  here  are  adapted  from 
those  in  the  PostScript  language,  which  was  developed  by  Adobe  Systems  Incorporated,  and  whose  specification 
has  been  placed  in  the  public  domain. 


Relationship  to  Standards  _  _  _ 


1)  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaeriptiont 


Sat  Xdga  Join  sets  the  current  edge  join  state  In  the  graphics 
state  to  edge  join  indicator.  This  establishes  the  shape  to  be  put 
at  the  corners  between  portions  (line  or  curve  segments)  of  the 
edges  of  filled  area  primitives.  The  following  edge  join  values  are 
supported : 

mitre  join  :  the  outer  edge  of  the  two  portions  are  extended 
until  they  meet  at  a  point.  (Note  that  the  mitre  limit  value 
may  affect  the  appearance  of  these  joins . ) 

round  join  :  a  circular  arc  with  diameter  equal  to  the  edge 
«ldth  Is  drawn  around  the  vertex  between  the  adjoining 
segments  and  Is  filled  in^  producing  a  rounded  corner. 

bevel  join  :  the  meeting  portions  are  finished  with  butt  end 
cap  and  the  resulting  triangular  notch  Is  filled  In. 

Other  values  are  reserved  for  future  registration  and 
standardization . 

Join  styles  are  significant  only  at  points  where  consecutive 
portions  of  an  edge  connect  at  an  angle;  portions  that  meet  or 
Intersect  fortuitously  receive  no  special  treatment. 
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Ralationahlp  to  partieular  atandarda; 


.  1)  COI  runctional  Spacifleation  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  funct*  >na.l  description  of  the  Set  Edge  Join  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

edge  join  indicator  (E) 


Items  for  Data 

Record: 

Integer 

IL 

1 

Integer 

IA(1) 

edge  join  indicator 

Integer 

RL 

0 

Integer 

SL 

0 

Data  Record  Description: 

The  parameter  defines  the  edge  join  index. 

2)  CGM  Sneodinga  (reference  ISO  8632  CGM;  Parts  2^3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"/  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


85 


3)  6KS  rvBctional  Oaseriptlon  (reference  ISO  7942  GKS 
functional  description) 

This  escape  is  applicable  at  level  Oa  of  GKS.  A  functional 
description  of  its  parameters  is  given  below: 


Hama 

escape  function  identifier 


Values 
as  assigned 


input  data  record* 

edge  join  indicator  (MITRE,  ROUND, 

BEVEL) 


Data  Type 
N 

E 


output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (EDJOIN) 

Input  Parameters: 

INTEGER  EDJOIN  edge  join  indicator  (MITRE,  ROUND, 

BEVEL) 


Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


INTEGER  IL 
INTEGER  1A(  1  ) 

INTEGER  RL 
INTEGER  SL 


1 


edge  join  indicator 
BEVEL) 

0 

0 


(MITRE,  ROUND, 


Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL  0 
INTEGER  RL  0 
INTEGER  SL  0 
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5)  Paseml  laaguaga  binding  (reference:  ISO  OIS  8651  6KS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape”  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


GEscapeEdgeJoin  *  (Mitre »  Rounds  Bevel) ; 

GREscapeDataIn  «  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

EdgeJoin  :  GEscapeEdgeJoin) ; 

END; 

GREscapeDataOut  -  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 

1:  {)  ;  (*Null  Record*) 

END; 


6)  GKS  Ada  Language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  pac)cage  name  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  paclcage,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SETJEDGE^JOIN"  form  (as  defined  in 
Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is: 


— Escape  function  for  a  set  line  join 

— Data  type  ESCAPE__ID  is  defined  in  package  GKS_ESCAPE . 
— Other  data  types”"are  defined  in  package  GKS_TYPES. 


with  GKS_TYPES; 
use  GKS__TYPES; 
package'~GKS  ESCAPES  is 

type  EDGE_JOIN  INDICATOR_TYPE  is  (MITRE,  ROUND,  BEVEL) ; 
EDGE_JOIN_INDICATOR_VALUE  :  in  EDGE_JOIN__INDICTOR_TYPE; 

procedure  SET_EDGE  JOIN 

(ESCAPE  IDENTIFIER  :in  ESCAPE_ID; 

EDGE  JOIN  INDICATOR  VALUE: in  EDGE  JOIN  INDICTOR  TYPE  ); 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Proposal  NumbT;  I 


Oats  of  Prosontstlon:  1 18  July  1988 


HM.tMjl.M 


CIsss  of  Qrsphleil  Hom:  I  ESCAPE 


Spoelfle  Eseapo  I  Function  Idontlflor:  I  Sat  Haile  Text 


Daserlptlon 


This  ascapa  function  aata  a  value  for  the  ftalfe  attributa  of  text  This  value  may  be  either  on,  indicating  that  text 
Is  drawn  in  an  Halle  stylo,  or  off,  indicating  that  text  Is  not  drawn  in  an  Haile  styta. 

Sea  attached  sheet  for  additional  details. 


Additional  Comments 


This  sscapo  is  intendad  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
baaed  upon  the  developing  ISO  font  arehHecture  (OP  9541). 


Justification  for  Inclusion 


Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  for  most  applications.  Most  proprietary  graphics  systems  currently  use  a  text  model  that  names  a  basic 
font  family  (such  as  Gothic)-  and  the  identilles  members  of  that  family  by  additional  syls  attributes  (such  as 
underline,  bold,  or  italic.)  Ibis  is  one  in  a  set  of  esespes  that  provide  similar  facilities  for  the  family  of 
computer  graphics  standards. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Da«eriafclon! 

S«t  Italic  Text  sets  the  current  italic  text  value  In  the 
graphics  state  to  the  value  specified  by  the  italic  text  indicator. 
This  establishes  whether  text  is  to  be  drawn. In  a  Italic  style.  The 
following  Italic  text  values  are  supported: 

OFF:  Italic  text  Is  set  to  OFF^  Indicating  that  text  Is  not 
drawn  In  an  Italic  style. 

ON:  Italic  text  Is  set  to  ONr  indicating  that  text  Is 
drawn  In  an  Italic  style. 

Values  other  than  OFF  and  ON  are  reserved  for  future  registration 
and  standardization. 

Relationship  to  particular _ standards ; 


1)  C6M  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Italic  Text  escape  parameters 
Is : 

Parameters : 

function  Identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

italic  text  indicator (OFF, ON)  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 


1 

Italic  text  Indicator 
0 
0 


Data  Record  Description:  ■ 

The  parameter  defines  the  Italic  text  Indicator. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2^3/4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  edded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6X8  runetlonal  Spaelfioatlon  {reference  ISO  7942  GKS 

Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 

description  of  its  parameters  is  given  below: 


Name  Values 

escape  function  Identifier  as  assigned 

input  data  record; 

Italic  text  indicator  (OFF,  ON) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,  WSOP,  ttSAC,  or  5GQP 

4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (ITTXT) 

Input  Parameters: 

INTEGER  ITTXT  italic  text  indicator  (OFF,  ON) 

Output  Parameters : 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  italic  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Paseal  laaguaga  bladiag  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "I"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


ItalicTextType  -  (GVEscapeOn, 

GVEscapeOff ) ; 

GREscapeDataIn  •  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

ItalicText  :  GEscapeltalicTextType) ; 

End; 

GREscapeDataOut  ■■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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€)  (SKS  Ada  laagoaga  blading  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS  ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provTdes  type 
declarations .  " 

The  binding  for  the  "procedure  SET_ITALIC_TEXT"  form  (as  defined  in 
Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is : 


— Escape  function  for  italic  text. 

"Data  type  ESC^E  ID  is  defined  in  package  GKS_ESCAPE. 
"Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  ITALIC__TEXT_INDICATOR_TYPE  is  (OFF,  ON)  ; 
type  ITALIC  TEXT_DATA_RECORD  is 

ITALIC_TEXT_INDICATOR_VALUE  :in  ITALIC_TEXT_INDICATOR_TYPE; 

procedure  SET_  ITALIC_TEXT 

(ESCAPE_IDENTIFIER  tin  ESCAPE_ID: 

ITALIC  TEXT  INDICATOR  VALUE  tin  ITALIC  TEXT  INDICATOR  TYPE) ; 


"more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 


92 


PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


I  Prepo««l  WumbT;  I  I 

i  Daf  ot  Pfantition;  i  18  Jutv  1988  1 

I  Spon«orlnq  Authority;  I  ANSI  I 

I  Cli«»  of  Oriphical  If  m;  I  ESCAPE  I 

I  SptGifIc  E»cip«  I  Function  IdtntlflT:  I  S«t  OutHn>  Text  ~| 

I  D>«crlptlon  I 


This  sscaps  function  sots  s  vaius  for  the  outline  attribute  of  text.  This  value  may  be  either  on,  indicating  that 
text  is  drawn  in  an  outline  style,  or  off.  indicating  that  text  is  not  drawn  in  an  outline  style. 

See  attached  sheet  for  additional  details. 


Additional  Comments 

This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  In  computer  graphics  standards 
based  upon  the  developing  ISO  font  architecture  (OP  9541). 


Justification  for  Inclusion 

Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  for  most  applications.  Most  proprietary  graphics  systems  currently  use  a  text  model  that  names  a  basic 
font  family  (such  as  Gothic)  and  the  Identifies  members  of  that  family  by  additional  syle  attributes  (such  as 
underline,  bold,  or  italic.)  This  is  one  in  a  set  of  escapes  that  provide  similar  facilities  for  the  family  of 
computer  graphics  standards. 


Relationship  to  Standards 

1)  ISO  7942  (GKS) *  *  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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DaaeglnfclQB 


8mt  Outlln*  T«3ti:  sets  the  current  outline  text  value  In  the 
graphics  state  to  the  value  specified  by  the  outline  text 
indicator.  This  establishes  whether  text  is  to  be  drawn  in  a 
outline  style.  The  following  Outline  text  values  are  supported: 

OFF:  outline  text  is  set  to  OFT,  Indicating  that  text  is  not 
dratm  in  an  outline  style. 

ON:  outline  text  is  set  to  OMf  indicating  that  text  is 
drawn  in  an  outline  style. 

Values  other  than  ON  and  OFF  are  reserved  for  future  registration 
and  standardization. 

Relationship  to _ partiCttlag _ standards : 


1)  C6M  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Outline  Text  escape  parameters 
is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

outline  text  indicator  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

outline  text  indicator 
0 
0 


The  parameter  defines  the  outline  text  indicator. 

2)  CGM  Ineodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  Gits  runetlonal  Specification  (reference  ISO  7942  GKS 

Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 

description  of  its  parameters  is  given  below: 


Name  Values 

escape  function  identifier  as  assigned 

input  data  record: 

outline  text  indicator  (OFF,  ON) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  WSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pgrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (OLTXT) 

Input  Parameters: 

INTEGER  OLTXT  outline  text  indicator  (OFF,  ON) 

Output  Parameters : 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  outline  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 


INTEGER  IL 
INTEGER  RL 
INTEGER  SL 


0 

0 

0 


5)  Vaaeal  languag*  binding  (refernnce:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

pia  folloifing  Pascal  language  binding  is  proposed  for  the  procedure 
GESMB"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1-  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


ExtendedTextType  «  (GVEscapeOn, 

. GVEscapeOf f ) ; 

GREscapeDataIn  *>  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 

ExtendedText  :  GEscapeOutlineTextType) ; 

End; 

GREscapeDataOut  •>  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 
1j  ()  ;  (*Null  Record  *) 

END; 
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6)  6KS  Ada  langnaga  blading  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_OOTLINE_TEXT"  form  (as  defined 
In  Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is : 


— Escape  function  for  Outline  text. 

—Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  OUTLINE  TEXT_INDICATOR_TYPE  is  (OFF,  ON) ; 
type  OUTLINE~TEXT_DATA_RECORD  is 

OUTLINE_TEXT_INDICATOR__VALUE  : in  OUTLINE_TEXT_INDICATOR_TYPE; 

procedure  SET__OUTLINE_TEXT 

(ESCAPE_IDENTIFIER  ; in  ESCAPE_ID: 

OUTLINE_TEXT_INDICATOR_VALUE  : in  OUTLINE  TEXT  INDICATOR  TYPE); 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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.  PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


I  D«f  of  Pf$>ntatlon;  1 18  July  1988  i 


i  3pontortnq  Authority!  I  ANSI  .  I 

i  Class  of  Graphical  If  m;  I  ESCAPE  I 

I  Sptclflc  Escap#  \  Function  Identifier;  I  Set  Shadow  Tert 


Dtacriptlon 

This  sscaps  function  sets  s  value  for  the  shadow  attribute  of  text  This  value  may  be  either  on,  indicating  that 
text  is  drawn  In  a  shadow  style,  or  off.  indicating  that  text  Is  not  drawn  in  a  shadow  style. 

See  attached  sheet  for  additional  details. 


Additional  Comments 

This  escape  is  intended  for  interim  use,  pending  the  revision  of  the  text  model  in  computer  graphics  standards 
baaed  upon  the  developing  ISO  font  arehitedture  (DP  9541). 


Justification  for  Inclusion 

Extensions  to  the  text  model  in  computer  graphics  standards  are  urgently  needed  if  such  standards  are  to  be 
usable  for  most  applications.  Most  proprietary  graphics  systems  currently  use  a  text  model  that  names  a  basic 
font  family  (such  as  Gothic)  and  the  identifies  members  of  that  family  by  additional  syle  attributes  (such  as 
underline,  bold,  or  italic.)  Tbis  is  one  In  a  set  of  escapes  that  provide  similar  facilities  for  the  family  of 
computer  graphics  standards. 


Relationship  to  Standards _ _ _ 

1)  ISO  7942  (GKS1  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM) *  *  Specifies  a  registered  escape  as  defined  in  5.8. 1 . 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaeriptlen; 

S«t  Shadow  Taxt  sets  the  current  shadow  text  value  In  the 
graphics  state  to  the  value  specified  by  the  shadow  text  indicator. 
This  establishes  whether  text  is  to  be  drawn  in  a  shadow  style.  The 
following  shadow  text  values  are  supported: 

OFF:  shadow  text  is  set  to  OFF,  indicating  that  text  is  not 
drawn  in  an  shadow  style. 

ON:  shadow  text  is  set  to  ON,  indicating  that  text  is 
drawn  in  an  shadow  style. 

Values  other  than  OFF  and  ON  are  reserved  for  future  registration 
and  standardization. 

Relationship  to  particular _ atandagdSJ. 


1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1 :  Functional  Description) 

A  functional  description  of  the  Set  Shadow  Text  escape  parameters 
is : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

shadow  text  Indicator  (E) 


Items  for  Data  Record: 

Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

shadow  text  indicator 
0 
0 


The  parameter  defines  the  shadow  text  indicator. 

2)  C(a<  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 


All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GXS  Functional  Spaelfleatlon  (reference  ISO  7942  GKS 

Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 
description  of  its  parameters  is  given  below: 

Name  Values  Data  Type 

escape  function  identifier  as  assigned  N 


input  data  record: 

shadow  text  Indicator  (OFF,  ON) 


E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 

4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (SHTXT) 

Input  Parameters: 

INTEGER  SHTXT  shadow  text  indicator  (OFF,  ON) 

Output  Parameters : 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  shadow  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GESCAPE"  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


ShadowTextType  -  (GVEscapeOn, 

(sVEscapeOf  f ) ; 

GREscapeOataIn  «  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 
1:  ( 

ShadowText  ;  GEscapeShadowTextType) ; 

End; 

GREscapeDataOut  -  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  GKS  Ada  lan5|uaga  bladlag  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS  ESCAPE.  GKS 
Ada  provides  a  data  type  package »  GKSJTYPES  which  provTdes  type 
declarations .  ~ 

The  binding  for  the  "procedure  SET_SHAOOW_TEXT"  form  (as  defined  In 
Paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  Is : 


— Escape  function  for  shadow  text. 

— Data  type  ESCAPE  ID  Is  defined  In  package  6KS_ESCAPE. 
— Other  data  types  are  defined  In  package'  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS  ESCAPE  Is 

type  SHADOW_TEXT_INDICATOR_TyPE  is  (OFF,  ON); 
type  SHADOW__TEXT_DATA_RECORD  is 

SHADOW_TEXT_INDICATOR_VALUE  :in  SHADOW_TEXT_INDICATOR_TYPE; 

procedure  SET_SHADOW_TEXT 

(ESCAPE_IDENTIFIER  tin  ESCAPE_ID: 

SHADOW  TEXT  INDICATOR  VALUE  tin  SHADOW  TEXT  INDICATOR  TYPE); 


0 

— more  ESCAPE  procedures  can  be  Inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Sp«cMIc  E«e«w  I  Function  Id^ntlltT:  \  S«t  Urwtoriifw  T>irt 


Additional  Commpnf 

This  aacapa  is  intandad  for  intarim  usa.  ponding  tha  ravision  of  tha  taxt  modal  in  computor  graphics  standards 
basad  upon  tha  dovaloping  ISO  font  architoeturo  (OP  9541). 


Justification  for  Inclualon 

Extsnsions  to  tha  taxt  modal  in  computar  graphics  standards  ara  urgently  naadad  if  such  standards  ars  to  bo 
usable  for  most  applications.  Most  proprietary  graphics  systems  currently  usa  a  taxt  modal  that  names  a  basic 
font  family  (such  as  Gothic)  and  tha  idontifias  mambars  of  that  family  by  additional  syia  attributes  (such  as 
undariina,  bold,  or  italic.)  This  is  one  In  a  sat  of  ascapas  that  provide  similar  facilities  for  the  family  of 
computar  graphics  standards. 


Relationship  to  Standards 

1)  ISO  7942  (GKS)  •  Spaeifias  a  registered  escape  as  daflnad  in  5.2. 

2)  ISO  8632  (CGM)  •  Spaeifias  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registarad  escapa. 

*AI  present  at  tha  stage  of  draft  The  status  of  this  relationship  is  provisional  until  this  standard  has  bean 
approved  by  ISO  council. 
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D#«erit>fcion; 


S«t  UndazllM  Tmxt  sets  the  current  underline  text  value  In  the 
graphics  state  to  the  value  specified  by  the  underline  text 
indicetor.  This  establishes  whether  text  Is  to  be  drawn  In  a 
underline  style.  The  following  underline  text  values  are  supported: 

OFF:  underline  text  Is  set  to  OFF^  Indicating  that  text  is  not 
drawn  In  an  underline  style . 

ON:  underline  text  Is  set  to  Ott,  Indicating  that  text  Is  drawn 
In  an  underline  style. 

Values  other  than  ON  and  OFF  are  reserved  for  future  registration 
and  standardization. 

Relatlonahlp  to _ particular  atandarda : 


1)  CGM  Functional  Specification  (reference  ISO  6632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Underline  Text  escape 
parameters  Is: 

Parameters : 

function  Identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (0) : 

underline  text  Indicator  (E) 


Items  for  Data  Record: 

Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Data  Record  Description: 


1 

underline  text  indicator 
0 
0 


The  parameter  defines  the  underline  text  Indicator. 

2)  C(SM  encodings  (reference  ISO  8632  CGM;  Parts  2^3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
recordr  containing  the  data  record  Items  In  sequential  order  from 
first  to  last#  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  IteT.s), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  Integers 
would  be  coded  as  If  It  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  6X8  Xvinetlonal  Spaeifieatioa  (reference  ISO  7  942  GKS 

Functional  Description) 

This  escape  is  applicable  at  GKS  level  Oa.  A  functional 
description  of  its  parameters  is  given  below: 


Hama  Values 

escape  function  identifier  as  assigned 

input  data  record: 

underline  text  indicator  (OFF,  OK) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors : 

S  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP/  WSAC,  or  SGOP 

4)  6XS  FORTRAH  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

StJBROUTINE  GEpqrs  (OLTXT) 

Input  Parameters: 

INTEGER  ULTXT  underline  text  Indicator  (OFF,  ON) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  underline  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Pascal  laaguaga  blndiag  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

^oHo'^ing  Pascal  language  binding  is  proposed  for  the  procedure 
"CTS^E"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "I"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


UnderllneTextType  -  (GVEscapeOn, 

GVEscapeOf f ) ; 


GREscapeDataIn  •  RECORD 


CJ^E  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

UnderlineText  :  GEscapeUnderlineTextType) ; 

End; 

GREscapeDataOut  »  RECORD 

CASE  Escape Id  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  6ICS  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  6KS 
Language  Bindings;  Part3:Acia) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS  ESCAPE.  GKS 
Ada  provides  a  data  type  package^  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  “procedure  SETJONDERLINE_TEXT"  form  (as  defined 
in  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  is: 


— Escape  function  for  underline  text. 

—Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  UNDERLINE_TEXT_INDICATOR_TYPE  is  (OFF,  ON) ; 
type  UNDERLINE_TEXT__DATA_RECORD  is 

UNDERLINE__TEXT_INDICATOR_VALUE  :  iri 

“  UNDERLINE_TEXT_INDICATOR_TYPE; 

procedure  SET_UNDERLINE__TEXT 

(ESCAPE_IDENTIFIER  : in  ESCAPE_ID : 
ONDERLINE_TEXT_INDICATOR  VALUE 

rin"  UNDERLINE_TEX^INDICATOR_TYPE  ); 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 

fPropotil  NuwbT;  j  ~ 


f  of  Pf fnftlon;  1 18  July  1988 


lontorlno  Authority;  I  ANSI* 


■s«  of  Qr«phlc«l  lUm;  I  ESCAPE 


•ctflc  Etcapp  I  Function  IdpntIfiT;  I  Sat  Bold  T«xt 


ipcrlptlon 


is  ssesps  function  sots  s  vsius  for  ths  bold  sttributs  of  toxL  This  vslus  may  bs  sithsr  on,  indicating  that  tsxt 
drawn  in  a  bold  styia,  or  off,  indicating  that  taxt  is  not  drawn  in  a  boid  styio. 
a  attachad  shaat  for  addHionai  dstaiis. 


iditional  Comments 


la  ascapa  is  intandad  for  intarim  uaa,  panding  tha  raiyision  of  tha  taxt  modai  in  computar  graphics  standards 
lad  upon  tha  davaioping  iSO  font  architactura  (OP  9541). 


atiftcatlon  for  Inctuaion 


lansions  to  tha  taxt  modai  in  computar  graphics  standards  ara  urgsntiy  nsadad  if  such  standards  ars  to  ba 
ibia  for  most  appiications.  Most  proprietary  graphics  systems  currantiy  use  a  taxt  modai  that  names  a  basic 
it  famiiy  (such  as  Gothic)  and  tha  identifies  msmbais  of  that  family  by  additional  syla  attributes  (such  as 
dariina,  bold,  or  italic.)  This  is  one  In  a  sat  of  escapes  that  provids  similar  facilities  for  the  famiiy  of 
nputar  graphics  standards. 


latlonship  to  Standards 


)  ISO  7942  (GKS)  •  Spadfias  a  ragistarad  ascapa  as  defined  in  5.2. 

)  ISO  8632  (CGM)  •  Specifies  a  ragistarad  escape  as  defined  in  5.8.1. 

ISO  8651  (GKS  Language  Bindings)  -  Specifies  a  registered  escape. 

present  at  tha  stage  of  draft.  Tha  status  of  this  relationship  is  provisional  until  this  standard  has  been 
xoved  by  ISO  council. 
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8«t  Bold  To3ct  aets  the  current  bold  text  value  In  the  graphlca 
state  to  the  value  specified  by  the  bold  text  indicator.  This 
establishes  whether  text  Is  to  be  drawn  In  a  bold  style.  The 
following  bold  text  values  are  supported: 

OFF:  bold  text  Is  set  to  OFF,  Indicating  that  text  Is  not  drawn 
In  an  bold  style. 

ON:  bold  text  Is  set  to  ONf  Indicating  that  text  Is  drawn  In 
an  bold  style.. 

Values  other  OFF  and  ON  are  reserved  for  future  registration  and 
standardization . 


1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Bold  Text  escape  parameters  is : 
Parameters : 

function  Identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (0) : 

bold  text  indicator (OFF, ON)  (E) 


Items  for  Data  Record: 


Integer  IL  1 

Integer  IA(1)  bold  text  Indicator 

Integer  RL  0 

Integer  SL  0 

Data  Record  Description: 

The  parameter  defines  the  bold  text  Indicator. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  In  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  In  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  Integers. 
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3)  6KS  runetlonal  Spaciflomtlon  (reference  ISO  7942  GKS 
Functional  Description) 

This  escape  Is  applicable  at  GKS  level  Oa.  A  functional  description 
of  Its  parameters  Is  given  below: 

Mama  Values  Data  Type 

escape  function  Identifier  as  assigned  M 

Input  data  record: 

bold  text  Indicator  (OFF,  ON)  E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  WSAC,  or  SGOP 

4)  GKS  FORTBAM  language  binding  (reference  ISO  DIS  865171  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  la  proposed  for  the  "GEpqrs”  form 
(as  defined  In  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  Is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (BLTXT) 

Input  Parameters: 

INTEGER  BLTXT  bold  text  indicator  (OFF,  ON) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  bold  text  Indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Pascal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 


The  following  Pascal  language  binding  is  proposed  for  the  procedure 
GESCAPE"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


BoldTextType  -  (GVEscapeOn, 

GVEscapeOf f ) ; 

GREscapeDataln  -  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

BoldText  :  GEscapeBoldTextType) ; 

End; 

GREscapeDataOut  »  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1j  ()  ;  (*Null  Record  *) 

END; 
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6)  6KS  Ada  laaguaga  binding  (reference  ISO  OIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package^  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_BOLD__TEXT"  form  (as  defined  in 
Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  Is: 


— Escape  function  for  bold  text. 

— Data  type  ESCAPE  ID  Is  defined  In  package  GKS_ESCAPE. 
— Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package^GKS  ESCAPE  Is 

type  BOLD~TEXT_INDICATOR_TYPE  is  (OFF,  ON) ; 
type  BOLD  TEXT_DATA__RECORD  is 

BOLD_TEXT_INDICATOR_VALUE  tin  BOLD_TEXT_INDICATOR_TYPE; 

procedure  SET_BOLD_TEXT 

(ESCAPE__IDENTIFIER  :  in  ESCAPE_ID : 

BOLD  TEXT  INDICATOR  VALUE  :in  BOLD  TEXT  INDICATOR  TYPE); 


— more  ESCAPE  procedures  can  be  Inserted  here 
end  GKS  ESCAPE; 


112 


PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Propo««l  NumbTn 


9  S«Dt«mb«r  1988 


Soonsorln 


Class  of  Qraohlcal  Itsm:  i  ESCAPE 


1  Function  Idontiflar:  ] 

rset  Ful 

Justified  Text  I 

OsserlDtlon 


This  sscaps  function  sots  a  vaius  for  tha  fuliy  justifiad  attributa  of  Taxi  This  valua  may  ba  aithar  on,  indicating 
that  Rastrictad  Taxt  is  drawn  in  a  fully  justifiad  styla,  or  off.  indicating  that  Rastricted  Text  is  not  drawn  in  a 
fully  justifiad  styla.  This  attributa  has  no  affact  on  tha  drawing  of  Taxt  or  Appand  Taxt  primitivas. 

Saa  attachad  shaat  for  additional  dataiis. 


Additional  Commanta 


This  sscapa  is  intandad  for  interim  use,  pending  tha  revision  of  tha  taxt  modai  in  computar  graphics  standards 
basad  upon  tha  davaloping  ISO  font  architactura  (DP  9541). 


Justification  for  Inclusion 


Extensions  to  tha  taxt  modal  In  computer  graphics  standards  aro  urgsntly  naadad  if  such  standards  are  to  ba 
usabia  for  most  applications.  Most  proprietary  graphics  systems  currently  allow  fully  justifiad  text  Such  taxf 
is  drawn  by  tha  target  system  by  varying  tha  spacing  between  words  In  a  taxt  string  to  insure  that  the  string 
starts  at  tha  beginning  of  a  restricted  region  and  ends  at  tha  and  of  tha  region.  Tha  Rastrictad  Text  primitive  in 
tha  existing  graphics  standards  partially  meats  this  goal,  but  its  semantics  allows  the  target  system  to  adjust 
taxt  by  many  different  means  to  meat  this  restriction.  This  escape  requires  that  tha  taxt  ba  fit  by  adjusting  only 
tha  intar-word  spacing  where  this  is  possibia.  Basad  on  ’minimality”,  it  was  decided  to  simply  add  an  attribute 


Relationship  to  Standards 


1 )  ISO  7942  (GKS)  •  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  escape  as  defined  In  5.8.1. 

*3}  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

”At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Daaeriytion? 


S«t  Fully  Justiflud  Tuxt  sets  the  current  fully  justified  text 
value  in  the  graphics  state  to  the  value  specified  by  the  fully 
justified  text  indicator.  This  establishes  whether  Restricted  Text 
primitives  are  to  be  drawn  in  a  fully  justified  style. 

Fully  Justified  text  is  defined  as  follows.  First,  just  as  with 
Restricted  Text,  the  fully  justified  text  is  constrained  to  be 
within  a  parallelogram  as  defined  for  Restriced  Text.  Second,  in 
fitting  the  text  within  this  parallelogram,  only  the  value  of 
Character  Spacing  for  the  spaces  between  words  may  be  adjusted. 
(Restricted  Text  allows  the  values  of  Character  Height,  Character 
Expansion  Factor,  Text  Precision,  and  TextFont  Index  to  be  adjusted 
also,  all  at  the  sole  discretion  of  the  system  drawing  the  text.) 
Third,  the  text  is  drawn  in  such  a  way  that  the  symbols  drawn 
appear  to  "fill”  the  parallelogram  along  the  text  path,  with  the 
first  and  last  symbols  drawn  against  the  sides  of  the 
parallelogram.  In  case  the  text  cannot  be  fit  within  the 
parallelogram  by  adjusting  only  the  Character  Spacing  value  for  the 
spaces  between  words,  then  the  text  will  be  drawn  using  the  rules 
for  Restructed  Text  in  general. 

The  following  fully  justified  text  values  are  supported: 

OFF:  fully  justified  text  is  set  to  OFF,  indicating  that 
Restricted  Text  is  not  drawn  in  a  fully  justified  style. 

O)^:  fully  justified  text  is  set  to  ON,  indicating  that 
Restricted  Text  is  drawn  in  a  fully  justified  style. 

Values  other  than  ON  and  OFF  are  reserved  for  future  registration 
and  standardization. 
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ailatignahtp  to  pagticular _ atandarda ; 


1)  CGM  runetional  Spaelfieatlon  (reference  ISO  8632  C6M; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Fully  Justified  Text  escape 
parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

fully  justified  text  indicator (OFF/  ON)  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 

Dhta  Record  Description: 


1 

fully  justified  text  indicator 
0 
0 


The  parameter  defines  the  fully  justified  text  indicator. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2/3/4) 


All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record/  containing  the  data  record  items  in  sequential  order  from 
first  to  last/  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string"/  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  iS/  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example/  in  the 
binary  encoding/  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4 .  Within  the  four 
octets  that  comprise  the  string's  contents/  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  OKS  runetlonal  Sp«ei£le«tion  (reference  ISO  7942  GKS 

Functional  Description) 

This  escape  Is  applicable  at  GKS  level  Oa.  A  functional 
description  of  Its  parameters  Is  given  below: 

Name  Values  Data  Type 

escape  function  Identifier  as  assigned  N 


Input  data  record:. 

fully  justified  text  Indicator  (OFF,  ON)  E 


output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfWSOP,  WSAC,  or  SGOP 


4)  GKS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  Is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (FJTXT) 

Input  Parameters: 

INTEGER  FJTXT  fully  justified  text  indicator (OFF,  ON) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  fully  justified  text  Indicator (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Paseal  laaguaga  binding  (referanca:  ISO  DIS  8651  GKS 
Languaga  Bindings;  Part  2:  Pascal) 

Tha  following  Pascal  languaga  binding  is  proposad  for  tha  procadura 
"GESCAPE”  as  dafinad  in  paragraph  6.2  of  tha  GKS  Pascal  language 
binding  (note  tha  case  variant  "I”  will  be  replaced  with  tha  actual 
ESCAPE  identifier  at  registration) : 


Fully Just if iedTaxt Type  -  (GVEscapaOn^ 

GVEscapeOff ) ; 


GREscapaOataIn  ■  ^CORD 

CASE  EscapalD  :  GTEscapaDataTag  of 
1;  ( 

FullyJustlf iedTaxt 

:  GEscape  FullyJustifiedTextTypa) ; 

End; 


GREscapaDataOut  ••  RECORD 

CASE  Escapeld  :  GTEscapaDataTag  of 
1:  0  ;  (*Null  Record  *) 


<)  GKS  Ada  laaguaga  biadlag  (referance  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part 3: Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GKSJTYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_FOLLY_^JUSTiriED  TEXT"  form  (as 
defined  in  Paragraph  4.1  of  the  GKS  Ada  Tanguage  binding)  of  the 
ESCAPE  is : 


— Escape  function  for  fully  justified  text* 

--Data  type  ESCAPE  ID  is  defined  in  package  GKS_ESCAPE. 
—Other  data  types  are  defined  in  package  GKS-TYPES. 


with  GKS  TYPES; 
use  GKS_TYPES; 
package^GES^ESCAPE  is 

type  FULLY_JUST1FIED_TEXT_INDICAT0R_TYPE  is  (OFF,  ON) ; 
type  FOLLY  JUSTIFIED_TEXT__DATA_RECORD  is 

FOLLY_JUSTIF1ED_TEXT__INDICATOR__VALOE  :  in 

FOLLY__JOSTIFIEDjrEXT_INDICATOR_TYPE; 

procedure  SET_FULLY_JOSTIFIED_TEXT 

(ESCAPE  IDENTIFIER  :in  ESCAPE_ID: 

FULLY  ^STIFIED  TEXT_INDICATOR  VALUE 

“  sin  FOLLY  JUSTIFIED  TEXT  INDICA’TOR  TYPE  )/ 


—more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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.  PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


PropoMi  Wumb>rn 


T-rirM-iMj;!iMmyii 


18  JulV  1988 


[Bmuiiii-  ■iHiELnu'aii 


ClPiP  of  Griphleal  Itom: 


itie  Eseapo  I  Function  Idontiflor:  I  Sot  Condonsod  Toxt 


Doaerlptlon 


Thia  ascapo  function  aota  a  vatua  for  tha  condanaad  attrfouta  of  taxL  This  valua  may  ba  aithar  on,  indicating  that 
tsxt  is  drawn  In  a  condanaad  stylo,  or  off,  indicating  that  taxt  is  not  drawn  in  a  condanssd  stylo. 

Saa  attachod  shoot  for  additional  datails. 


Additional  Comments 


This  aseapa  is  intandod  for  tntarim  usa,  ponding  tha  revision  of  tha  toxt  nwdal  in  computar  graphics  standards 
basad  upon  tha  davaloping  ISO  font  arehitaeturo  (OP  9541). 


justification  for  Inclusion 


Extansions  to  tha  taxt  modal  in  computar  graphics  standards  ara  urgently  naadsd  if  such  standards  arc  to  ba 
usable  for  most  applicalions.  Most  propriataiy  graphics  systems  currently  usa  a  taxt  modal  that  names  a  basic 
font  family  (such  as  Gothic)-  and  the  Mantillas  mambars  of  that  family  by  additional  syla  attributes  (such  as 
undorlino,  boM,  or  italle.)  Many  systems  foduda  axtandad  wd  condanssd  styes  of  text,  where  tha  font  designer 
spacHlas  changes  In  character  spiwing  to  aehiava  tha  condensed  or  extended  appearance.  Although  these  effects 
couM  ba  crudely  approximalod  by  varying  tha  Character  Spacing  attribute  of  graphical  toxt,  such  an 

ximation  is  Inaopreoriata  for  svsterrMi  that  raouira  hloh-oualltY  taxt  This  is  ona  in  a  sal  of  escapes  that 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  •  Spadfias  a  ragistarad 


as  dafinad  in  5.2. 


2)  ISO  8632  (CGM)  •  Spadfias  a  ragistarad  escape  as  dafinad  In  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Spadfias  a  ragtsterad  escape. 

*At  present  at  tha  stage  of  draft.  Tha  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 


L9 


S«t  Coad«a««d  T«xt  sets  the  current  condensed  text  value  In  the 
graphics  state  to  the  value  specified  by  the  condensed  text 
indicator.  This  establishes  whether  text  Is  to  be  drawn  In  a 
condensed  style.  The  following  Condensed  text  values  are  supported: 

OFF:  condensed  text  Is  set  to  OFF#  Indicating  that  text  is  not 
drawn  In  an  condensed  style. 

ON:  condensed  text  Is  set  to  ON,  Indicating  that  text  is 
dratm  in  an  condensed  style. 

Values  other  than  OFF  and  ON  are  reserved  for  future  registration 
and  standardization. 

Relationship  to  particular  afcandarda: 


1)  CGM  Functional  Specification  (reference  ISO  8632  C6M; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Condensed  Text  escape 
parameters  Is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  <D) : 

condensed  text  indicator (OFF, ON)  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 

Integer  RL 
Integer  SL 

Data  Record  Description: 

The  parameter  defines  the  condensed  text  indicator. 

2)  COI  Ineodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


1 

condensed  text  indicator 
0 
0 
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3)  6XS  runetional  Specification  (reference  ISO  7942  6KS 

Functional  Description) 

This  escape  is  applicable  at  6KS  level  Oa.  A  functional 
description  of  Its  parameters  la  given  below: 


Name  Values 

escape  function  identifier  as  assigned 

input  data  record: 

condensed  text  indicator  (OFF,  ON) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,»SOP,  WSAC,  or  SGOP 

4)  GKS  rORTKAM  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs"  form 
(as  defined  in  Paragraph  9.1  of  the  6RS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SDBROOTINE  GEpqrs  ((^ITXT) 

Input  Parameters: 

INTEGER  CNTXT  condensed  text  indicator  (OFF,  ON) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  condensed  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) ; 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  PMcal  language  blading  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 


Pascal  language  binding  is  proposed  for  the  procedure 
CTSWE"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


CondensedTextType  •  (GVEscapeOn, 
(^scapeOff ) ; 


(HlEscapeOataln  •  RECORD 


CASE  Escape  ID  :  (STEscapeDataTag  of 
1:  ( 

CondensedText  :  GEscapeCondensedTextType) ; 

End; 

GREscapeDataOut  *  RECORD 

CASE  Escape Id  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record  *) 

END; 
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8)  GKS  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package#  GKS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_CONDENSED_TEXT"  form  (as  defined 
In  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  Is: 


— Escape  function  for  condensed  text. 

—Data  type  ESCAPE  ID  Is  defined  In  package  GKS_ESCAPE. 
—Other  data  types  are  defined  In  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  Is 

type  CONDENSED  TEXT_INDICATOR  TYPE  is  (OFF#  ON) ; 
type  CONDENSED""tEXT_DATA  RECORD  is 

CONDENSED_TEXT_INDICAfOR_VALUE  : in 

CONDENSED_TEXT_IND  ICATOR__T  YPE  ; 

procedure  SET_CONDENSED_TEXT 

(ESCAPE_IDENTIFIER  tin  ESCAPE_ID: 
CONDENSED_TEXT_IND ICATOR_VALOE 
tin  CONDENSED  TEXT  INDICATOR  TYPE); 


— more  ESCAPE  procedures  can  be  Inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Propo»«i  Wumb«n1 


iPlEM-lMin’T  l.U  Ut'IiWIEETirMma 


Spontorin 


Clast  of  Qraphleal  Itom:  I  ESCAPE 


itie  Eseaoo  I  Function  Idontiflar:  I  Sol  Extondod  Toxt 


Ooserlptlon 


This  oseapo  lunction  sols  a  vaiuo  for  Iho  oxtsndad  attributo  of  text  This  valua  may  ba  aithar  on,  indicating  that 
text  is  drawn  in  an  axtendad  alyte.  or  off,  indicating  that  text  is  not  drawn  in  an  axtandsd  stylo. 

Saa  attachad  shoot  for  addition^  datails. 


Additional  Commanta 


This  ascapa  is  inlsndad  for  intarim  yaa,  ponding  tha  ravision  of  tea  text  modal  in  eomputsr  graphics  standards 
basad  upon  tha  davaloping  ISO  font  architoetura  (DP  9541). 


Justification  for  Inclusion 


Extensions  to  tha  text  modal  in  computer  graphics  standards  are  urgently  nsadsd  if  such  standards  are  to  bs 
usable  for  most  applications.  Most  propriatary  graphics  systems  currsntty  use  a  toxt  model  that  names  a  basic 
font  family  (such  as  Gothic)  and  tea  idantiltes  mambars  ol  that  family  by  additional  syle  attributes  (such  as 
underline,  bold,  or  italic.)  Many  systems  ineluda  axtendad  and  condensed  styes  of  text,  where  the  font  designer 
spaciftes  changes  in  character  spacing  to  achiaea  tea  condensed  or  extended  appearance.  Although  these  effects 
could  bs  crudely  approximated  by  varying  tha  Character  Spacing  attributa  of  graphical  text  such  an 
approximation  is  inaooropriata  for  systems  that  rsouira  hloh-ouallty  text  This  Is  one  in  a  sat  of  escapes  that 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Spsdfias  a  ragistersd  ascapa  as  defined  in  5.2. 

2)  ISO  8632  (CGM)  >  Specifies  a  registarsd  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  tha  stags  of  draft  Tha  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Daaeriatlan: 


S«t  Cxtandad  T«xt  sets  the  current  extended  text  value  In  the 
graphics  state  to  the  value  specified  by  the  extended  text 
indicator.  This  establishes  whether  text  is  to  be  drawn  in  an 
extended  style.  The  following  extended  text  values  are  supported: 

OFF:  extended  text  is  set  to  OFF,  indicating  that  text  is  not 
drawn  in  an  extended  style. 

ON:  extended  text  is  set  to  ON,  indicating  that  text  is  drawn 
in  an  extended  style. 

Values  other  than  OFF  and  ON  are  reserved  for  future  registration 
and  standardization. 

Relationahin  to _ particular _ atandarda  ; 


1)  CGM  Functional  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

A  functional  description  of  the  Set  Extended  Text  escape  parameters 
is : 

parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 

extended  text  indicator (OFF, ON)  (E) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 

Integer  RL 
Integer  SL 

Data  Record  Description: 

The  parameter  defines  the  extended  text  indicator. 

2)  C(jM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  'Tom 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 


1 

extended  text  indicator 
0 
0 
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3)  6XS  rtiaetlonal  Spaeifieatlon  (reference  ISO  7  942  6KS 

FunctloAal  Description) 

This  escape  Is  applicable  at  GKS  level  Oa.  A  functional 

description  of  its  parameters  is  given  below: 


Hama  Valuas 

escape  function  identifier  as  assigned 

input  data  record: 

extended  text  indicator  (OFF,  ON) 


Data  Type 
N 

E 


output  data  record: 
none 


Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOPfttSOP,  WSAC,  or  SGOP 

4)  6XS  FORTRAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs”  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (EXTXT) 

Input  Parameters: 

INTEGER  EXTXT  extended  text  indicator  (OFF,  ON) 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 

INTEGER  IL  1 

INTEGER  IA(  1  )  extended  text  indicator  (OFF,  ON) 

INTEGER  RL  0 
INTEGER  SL  0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 

INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 
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5)  Pascal  laagoaga  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GESCAPE"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  registration) : 


ExtendedTextType  -  ((^VEscapeOn, 

GVEscapeOf f ) ; 

GREscapeDataIn  «  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  ( 

ExtendedText  :  GEscapeExtendedTextType) ; 

End; 

GREscapeDataOut  >■  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record  *) 

END; 
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6)  6X3  Ada  laaguaga  binding  (reference  ISO  DIS  8651/3  GKS 

Language  Bindings;  Part3:Ada) 

Registered  ESCAPE'S  are  In  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package^  GKS_TyPES  which  provides  type 
declarations. 

The  binding  for  the  "procedure  SET__EXTE11DED_TEXT”  form  (as  defined 
In  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the  ESCAPE  Is: 


— Escape  function  for  extended  text. 

— Data  type  ESCAPE  ID  Is  defined  in  package  GKS__ESCAPE. 
— Other  data  types  are  defined  In  package  GKS-TYPES. 


with  GKS_TYPES; 
use  GKS^TYPES; 
package^GKS  ESCAPE  Is 

type  EXTENDED__TEXT_INDICATOR__TYPE  is  (OFF,  ON)  ; 
type  EXTENDED  TEXT_DATA_RECORD  is 

EXTENDED_TE5(T_INDICATOR_VALUE  tin  EXTENDED_TEXT_INDICATOR_TYPE; 

procedure  SET_EXTENDED_TEXT 

(ESCAPE_IDENTIFIER  tin  ESCAPE  ID: 

EXTENDED__TEXT_INDICATOR_VALOE:in  EXTENDED_TEXT_1NDICAT0R_TYPE) ; 


— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEMS 


Proposal  Numbar:  I 


10  April  1987 


Class  of  Oraphical  Itam 


OOP  IdsntIflor 


lEnmni 


Daserlptlon  _ _ 


This  Gsnaralizsd  Drawing  Primitivs  provMss  a  vary  lisxibla  mschanlsm  for  dsscribing  raster  (image)  data 
within  computer  graphics  standards.  It  can  be  viewed  as  an  extension  of  the  Cell  Array  primiHve  to  allow 
alternate  encoding  and  compression  schemes.  See  attached  sheet  for  additional  details. 


Additional  Comments 


The  features  in  this  GOP  are  baaed  upon  those  in  the  Cell  Array  primitive,  with  extensions  adopted  from  CCITT 
T.4  and  T.6.  Tag  Image  File  Format(TIFF).  and  Tiled  Raster  Interchange  Format  (TRIF)  as  needed,  to  meet  the 
requirements  of  intended  appiieations. 


Justification  for  Inclusion 


The  raster  data  capabilities  of  existing  graphics  standards  provide  a  nch  and  flexible  set  of  facilities  for  dealing 
with  raster  (image)  data.  These  facilities  do,  however,  iadr  a  few  features  that  limit  their  wider  applicability 
and  often  force  users  to  utilize  techniques  outside  of  computer  graphics  standards  to  describe/lransfer  raster 
data.  This  GOP  is  intended  to  add  the  missing  facilities.  With  it,  a  single  file  format— the  CGM — can  meat  the  needs 
of  both  raster  and  'vector* *  graphics  storage  and  exchange  in  office,  publishing,  and  other  applications. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  GOP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GOP  as  defined  in  5.6.10. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  GDP.  (See  attached  sheets). 

'At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaerlatlani 


Th«  Pel  Array  generalized  drawing  primitive  Is  an  extended  version 
of  the  Cell  Array  primitive  designed  to  support  the  transfer, 
storage,  and  printing  of  raster  Image  data  from  a  variety  of 
sources . 

Parameters : 

3  corner  points  P,Q,  and  R  (3P) 

nx,ny  (number  of  pels  per  line;  number  of  lines)  (21) 
encoding  (one  of:  packed,  run-length,  T.4,  T.6,  LZW)  (E) 
local  colour  precision 

pel  array  colour  specifiers  (nx*ny*local  colour  precision) 

In  the  general  case,  P,Q,R  can  delimit  an  arbitrary  pallelogram.  P 
and  Q  delimit  the  end  points  of  a  diagonal  of  the  parallelogram, 
and  R  defines  a  third  corner. 

In  the  simplest  case,  the  three  corner  points,  P,Q,R,  define  a 
rectangular  area  In  the  coordinate  space.  This  area  Is  subdivided 
Into  nx*ny  contiguous  rectangles  as  follows.  The  edge  from  P  to  R 
Is  subdivided  Into  nx  equal  Intervals,  and  the  edge  from  R  to  Q  Is 
subdivided  Into  ny  equal  Intervals.  The  grid  Implied  consists  of 
nxfny  Identical  pels.  The  colour  list  consists  of  nx*ny  colour 
specifications,  conceptually  an  array  of  dimensions  nx  and  ny 
representing  respectively  the  column  and  row  dimensions.  Array 
element  (1,1)  Is  mapped  to  the  pel  at  corner  P,  and  array  element 
(nx,l)  Is  mapped  to  pel  at  corner  R.  Array  element  (nx,ny)  Is 
mapped  to  the  pel  at  corner  Q.  Hence,  the  colour  elements  are 
mapped  within  rows  running  from  P  to  R,  and-  with  the  rows 
Incrementing  In  order  from  R  to  Q.  (Note  that  all  four  traditional 
values  of  pel  path  —  0,  90,  180,  and  270  —  as  well  as  both 
traditional  values  of  line  progression  —  90  and  270  —  can  be 
realized  by  varying  the  Inter-relatlonshlps  among  P,  Q,  and  R] 

The  encoding  parameter  specifies  how  the  pel  array  values  are 
encoded.  This  parameter  allows  an  API  standard  to  pick  up  a  pel 
array  (Image)  obtained  from  an  external  device,  such  as  a  scanner, 
and  Image  (print)  It  without  having  to  Interpret  the  data  In  It. 
Similarly,  It  allows  a  graphical  metafile  or  Interface  standard  to 
transfer  such  data  without  having  to  Interpret  It .  The  allowable 
values  of  encoding  are: 


Packed  :  No  compression,  but  pack  colour  values  as  tightly  as 
possible,  with  no  unused  bits  except  at  the  end  of  a  row.  The 
colour  values  are  represented  by  rows  of  values,  each  row  starting 
on  a  (16  bit)  word  boundary.  (Note:  This  encoding  Is  Identical  to 
the  "packed  list”  mode  In  the  binary  binding  of  the  CGM.  It  Is  also 
equivalent  to  the  "packed"  mode  of  TIFF,  with  byte  order  restricted 
to  "MM".] 
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Rvn-lMgth  The  colour  list  values  are  represented  by  rows 
broken  Into  runs  of  constant  colour;  each  row  starts  on  a  (16  bit) 
word  boundary.  [Note:  This  encoding  Is  Identical  to  the  "packed 
list"  mode  In  the  binary  binding  of  the  CGM.] 

T.4  one  dimensional  Facsimile-compatible  CCITT  Group  3f 
exactly  as  specified  In  "Standardization  of  Group  3  facsimile 
apparatus  for  document  transmission"  Recommendation  T.4  Volume  vii, 
Fascicle  VII. 3f  Terminal  Equipment  and  Protocols  for  Telematic 
Services r  The  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT)/  Geneva/  1985/  pages  16  through  21.  All  rows 
must  begin  on  a  byte  boundary.  The  restrictions  In  T.4  for  the 
number  of  pels  per  line  (nx) ,  the  number  of  lines  per  pel  array 
(ny)  /  and  the  size/  position/  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  (Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundaries  is  not  required 
but  Is  allowed. ] 

t.4  two  dimensional  :  Facsimile-compatible  CCITT  Group  3  two 
dimensional/  exactly  as  specified  in  "Standardization  of  Group  3 
facsimile  apparatus  for  document  transmission”  Recommendation  T.4 
Volume  VII/  Fascicle  VII. 3/  Terminal  Equipment  and  Protocols  for 
Telematic  Services/  The  International  Telegraph  and  Telephone 
Consultative  Committee  (CCITT)/  Geneva/  1985/  pages  21  through  28. 
All  rows  must  begin  on  a  byte  boundary.  The  restrictions  in  T.4  for 
the  number  of  pels  per  line  (hx) /  the  number  of  lines  per  pel  array 
(ny)/  and  the  size/  position/  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  [Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundaries  Is  not  required 
but  Is  allowed.] 

T.6  :  Facsimile-compatible  CCITT  Group  4,  exactly  as  specified  in 
"Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group  4 
Facsimile  Apparatus"/  Recommendation  T.6/  Volume  VII/  Fascicle 
VII. 3.  Terminal  Equipment  and  Protocols  for  Telematic  Services/  The 
International  Telegraph  and  Telephone  Consultative  Committee 
(CCITT)/  Geneva/  1985/  pages  40  through  48.  The  restrictions  in  T.4 
for  the  number  of  pels  per  line  (nx)  /  the  number  of  lines  per  pel 
array  (ny) ,  and  the  size/  position/  and  orientation  of  an  pel  array 
within  a  picture  do  not  apply.  [Note  that  the  addition  of  fill  bits 
before  EOLs  to  force  them  to  end  on  word  boundaries  is  not  required 
but  Is  allowed.]  (Note:  This  encoding  is  identical  to  that  of  the 
T.4  two  dimensional  with  the  single  exception  that  the  "K” 
parameter  which  controls  the  number  of  consecutive  two  dimensional 
lines  without  an  Intervening  one  dimensional  line  has  the  value 
Infinity  rather  than  a  small  Integer.] 

LEW  Compression  An  adaptive  compression  for  raster  images  as 
defined  in  an  article  by  Terry  A.  Welch/  entitled  "A  Technique  for 
High  Performance  Data  Compression”/  IEEE  Computer  /  vol.  17  no.  6 
(June  1984)/  and  called  the  basic  Lempel-Ziv  &  Welch  (LZW) 
algorithm.  [Note:  The  author's  goal  in  that  article  was  to  describe 
a  hardware-based  compressor  that  could  be  built  into  disk 
controller  or  database  engine/  and  used  on  all  types  of  data.  There 
is  no  specific  discussion  of  raster  images.] 

J.ZW  is  fully  reversible.  All  information  is  preserved/  but  if  noise 
vr  information  is  removed  from  an  image/  perhaps  by  smoothing  or 
zeroing  some  low-order  bitplanes/  LZW  compresses  images  into  a 
smaller  size.  ThuS/  5-bit/  6-bit/  or  7-bit  data  masquerading  as 
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8-blt  data  compreasaa  batter  than  true  B^blt  data.  Smooth  Images 
also  coihpress  better  than  noisy  ImageSf  and  simple  Images  compress 
better  than  conqplex  images.  LZW  works  well  on  bilevel  images  too. 
It  generally  ties  T.4  one  dimensional  (Modified  Huffman) 
compression,  on  test  Images  while  LZW  seems  to  be  considerably  fa 

LZW  Encoding 

The  LZW  algorithm  is  based  on  a  translation  table,  or  string  table, 
that  maps  strings  of  input  characters  into  codes.  Variable-length 
codes  are  used,  with  a  maximum  code  length  of  12  bits.  This  string 
table  is  different  for  every  pel  array,  and,  remarkably,  does  not 
need  to  be  kept  for  the  decompressor.  The  trick  is  to  make  the 
decompressor  automatically  build  the  same  table  as  is  built  when 
compressing  the  data.  The  following  C-llke  pseudocode  describes  the 
coding  scheme : 

InitializeStrlngTable 0 ; 

HrlteCode (ClearCode) ; 

SI  •  the  en^ty  string 

for  each  character  in  the  pel  array { 

K  "  GetNextOctet ( ) ; 

if  il+K  is  the  string  table  ( 

SI  -  Q>K;  /*  string  concatenation*/ 

}elae( 

WrlteCode  (CodeFromStrlng(i2) ) ; 

AddTableEntry (Q) ; 
n  -  K; 

} 

}/*end  of  for  loop*/ 

WrlteCode (CodeFromStrlng (Q) ) ; 

WrlteCode (Endof Information) ; 

The  "characters"  that  make  up  LZW  strings  are  octets  of 
uncompressed  pel  array  data.  InitializeStrlngTable 0  initializes 
the  string  table  to  contain  all  256  possible  single  octet  codes, 

numbered  0  through  255.  WrlteCode ()  writes  a  code  to  the  output 

stream.  The  first  code  written  is  a  Clear  code,  which  is  defined  to 
be  code  #256.  Q  represents  the  "prefix"  string.  GetNextOctet () 
retrieves  the  next  octet  from  the  input  stream.  The  "■•■"  sign 
indicates  string  concatenation. 

AddTableEntry ( )  adds  a  table  entry.  Since  InitializeStrlngTable  has 
already  added  256  entries  to  the  table,  and  since  entry  256  is 
reserved  for  a  special  "clear  code",  and  entry  #257  is  reserved  for 
a  special  "End  of  Information"  code,  therefore  the  first 
multi-octet  entry  to  the  table  is  made  at  position  258. 

Since  codes  are  written  using  as  few  bits  as  possible,  WrlteCode () 

starts  out  with  9  bit  codes  since  the  new  entries  are  greater  than 
255  but  less  than  512.  When  table  entry  512  is  added,  WrlteCode 
switches  to  10  bit  codes.  Likewise,  it  switches  to  11  bit  codes  at 
1024  and  to  12  bit  codes  at  2048.  The  table  is  limited  to  12  bit 
codes,  so  when  entry  4094  is  reached,  a  ClearCode  is  written  and 
the  compresor  re-initilaizes  the  table  and  starts  writing  out  9  bit 
codes  again.  Each  encoded  pel  array  begins  with  a  Clear  code  and 
ends  with  an  End  of  Information  code. 
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LZW  Decoding 

The  procedure  for  decompression  Is  described  by  the  following 
pseudocode : 

while  ( (CodeNextCode () !*Cnd  of  Information  code) ( 
if  ( (Code  Clear  code) { 

InitializeTable 0 ; 

Code  -  GetNextCode ( ) ; 
if  (Code  ««•  End  of  Information  code  ) 
break; 

WrlteCode (StringFromCode (Code) ) ; 

OldCode  *  Code; 

}  */end  of  Clear  code  case*/ 

else( 

if  (IsInTable (Code) )  ( 

WriteString (StringFromCode (Code) ) ; 

AddStringToTable  (StringFromCode  (OldCode)  -t-FirstChar 
(StringFromCode (Code) ) ) ; 

WriteString (OutString) ; 

AddStringToTable (OutString) ; 

OldCode  Code; 

)else( 

Ou  t  S  t  r  ing*St  r  ingF  ronKIode  (OldCode ) 

+  FirstChar (StringFromCode (Code) ) ; 

AddStringToTable (OutString) ; 

OldCode  •  Code; 

WriteString (OutString) ; 

) 

)/*end  of  not "Clear  code  case*/ 

)/*end  of  while  loop*/ 

The  function  GetNextCode  ( )  retrieves  the  next  code  from  the 
LZW-coded  data.  It  must  keep  track  of  bit  boundaries.  It  knows  that 
the  first'  code  that  it  gets  will  be  9-bit  code.  We  add  a  table 
entry  each  time  we  get  a  code,  so  GetNextCode ()  must  switch  over  to 
10-bit  as  soon  as  string  #511  is  stored  into  the  table. 

The  function  StringFromCode ()  gets  the  string  associated  with  a 
particular  code  from  the  string  table. 

The  function  AddStringToTable ()  adds  a  string  to  the  string  table. 
The  sign  joining  the  two  parts  of  the  argument  to 

AddStringToTable  indicate  the  string  concatenation. 

StringFromCode ()  looks  up  the  string  associated  with  a  given  code. 

WriteString 0  adds  a  string  to  the  output  stream. 


The  'local  colour  precision'  parameter  declares  the  precision  of 
'cell  colour  specifiers'.  It  applies  only  to  computer  graphio.s 
standards  that  support  the  both  direct  and  indexed  specification  of 
colour.  If  Indexed  colour  selection  is  used,  then  this  parameter 
specifies  the  colour  index  precision.  If  direct  colour  selection  is 
used,  then  then  this  parameter  specifies  the  colour  precision. 
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Ralafeianahin _ tfl _ PlgtiCttllg _ standards : 

1)  C6M  runetloaal  Spaelfleatien  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  LCP  (local  color  precision)  parameter  declares  the  precision  of 
the  cell  colour  specifiers.  The  precision  is  for  either  indexed  or 
direct  colour,  according  to  the  COLOUR  SELECTION  MODE  of  the 
picture.  The  form  of  the  parameter  is  encoding  dependent.  If  the 
picture  uses  indexed  colour  selection,  then  the  form  of  the 

parameter  is  the  same  as  that  of  COLOUR  INDEX  PRECISION.  If  the 
picture  uses  direct  colour  selection,  then  the  form  of  the 

parameter  is  the  same  as  that  of  COLOUR  PRECISION.  Since  the  array 
may  be  compressed,  its  length  may  not  be  able  to  be  calculated 
directly  from  the  number  of  pel  array  colour  specifier  values. 

Consequently,  the  pel  array  is  treated  as  an  array  of  16  bit 

integer  words  and  its  length  is  specified  by  the  pel  array  length 
parameter . 

A  functional  description  of  the  Pel  Array  generalized  drawing 
primitive  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 
Authority 

point  list(nP)  contains  the  three  points  P,  Q,  and  R 

data  record (D) 


Items  for  Data  Record: 

Integer  IL  5  >  pel  array  length  (which  depends  the 

relationship  of  LCP  to  integer  precision 
integer  precision  and  encoding) 

Integer  IA(1)  nx 

Integer  IA(2)  ny 

Integer  IA(3)  encoding 

Integer  IA(4)  LCP 

Integer  IA(S)  pel  array  length 

Integer  IA(6)  start  of  pel  array  colour  specifiers 

Integer  RL  0 
Integer  SL  0 

Data  Record  Description: 

The  data  record  contains  the  dimensions  of  the  pel  array,  its 
encoding  type,  its  local  colour  precision,  and  the  pel  array 
itself . 
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2)  CGM  laeodlaga  (reference  ISO  8632  C6M;  Parts  2,3^4) 

All  encodings  will  be  handled  In  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  within  the  four 
octets  that  conqprlse  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 

3)  6KS  Functional  Specification  (reference  ISO  7942  GKS 
Functional  Description) 

This  GDP  is  applicable  at  level  Oa  of  GKS.  The  corner  points  are 
transformed  to  NDC  and  the  pel  array  through  those  points  is  then 
drawn.  The  pel  array  colour  specifiers  may  be  either  index  or 
direct  colour  values,  as  determined  by  the  value  of  the  colour 
specification  type  parameter.  If  the  pel  array  uses  Indexed  colour 
selection,  then  the  local,  colour  precision  specifies  the  length  of 
the  index  values  in  bits.  If  the  pel  array  uses  direct  colour 
selection,  then  the  local  colour  precision  specifies  the  length  of 
the  direct  RGB  colour  values  in  bits.  Since  the  array  may  be 
compressed,  its  length  may  not  be  able  to  be  calculated  directly 
from  the  number  of  pel  array  colour  specifier  values .  Consequently, 
the  pel  array  is  treated  as  an  array  of  16  bit  integer  worda  and 
its  length  is  specified  by  the  pel  array  length  parameter. 

A  functional  description  of  all  input  parameters  is: 


Name  Coordinate  System  Values  Data  Type 

number  of  points  (3)  I 

corner  points  (P,Q,  and  R)  WC  3xP 


GDP  identifier  as  assigned  N 

GDP  data  record: 
nx,ny  (21) 

encoding  (packed,  run-length,  T.4,  T.6,  LZW)  E 

colour  specification  type  (indexed,  direct)  E 

local  colour  precision  I 

pel  array  length  I 

pel  array  colour  specifiers  (nx*ny*local  colour  precision)  I*pel 

array 

length 
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Errors: 


5  GKS  not  in  proper  state:  GKS  shall  be  either  in  the  state 
WSAC  or  in  the  state  SGOP 
100  Nwnber  of  points  is  invalid 

4)  6XS  rORTBAN  Isngusgo  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  Is  proposed  for  the  "GDpqrs”  form 
(as  defined  In  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  GDP  (pqrs  Is  to  be  assigned  by  the  Registration  Authority  to 
correspond  to  the  assigned  Register  Identifier) : 


SUBROUTINE  GDpqrs (  N,  PXA,  PYA,  NX,  NY,  lENCODE,  ICSPEC,  LCP, 
+IPAL,  IPACS) 


Input  Parameters: 
INTEGER  N 

REAL  PXA(3),  PYA(3) 
INTEGER  NX,  NY 

INTEGER  lENCODE 

INTEGER  ICSPEC 

INTEGER  LCP 
INTEGER  IPEL 
INTEGER  IPACS (IPEL) 


number  of  points  (3) 

P,Q,  and  R  corner  points 

number  of  pels  per  line;  number  of 

lines 

encoding  (packed,  run- length,  T.4,  T.6, 
LZW) 

colour  specification  type (Indexed, 
direct) 

local  colour  precision 
pel  array  length 

pel  array  colour  specifiers 
(number  of  values  is  nx*ny*local  colour 
precision) 


b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  GDP  through  the  GGDP  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 


Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


Integer  IL 


Integer  IA(1) 
Integer  IA(2) 
Integer  IA(3) 
Integer  IA(4) 
Integer  IA(5) 
Integer  IA(6) 


5  pel  array  length  (which  depends  the 
relationship  of  LCP  to  Integer  precision 
Integer  precision  and  encoding) 
nx 
ny 

encoding 

LCP 

pel  array  length 

start  of  pel  array  colour  specifiers 


Integer  RL  0 

Integer  SL  0 
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5)  Pascal  language  blading  (reference:  ISO  OIS  6651  GKS 

Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  is  proposed  for  the  procedure 
"GEscape"  as  defined  in  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  ”1"  will  be  replaced  with  the  actual 
ESCAPE  identifier  at  regiswiatlon) : 

NumPoints  *3; 

Points  :  GAPointArray; 

GEGDPCurveProperty6  *  (paeJeed#  run-length,  T.4,  T.6,  LZW) ; 
GEGDPCurveProperty7  <■  (indexed,  direct); 


GRGDPData  -  RECORD 

CASE  GDP Id  :  GTGDPDataTag  OF 
1:  ( 

PelsPerLine 

LinesPerArray 

EncodingType 

ColourSpecificationType 

LocalColourPrecision 

Pe 1 Ar rayLength 

PelArrayColourSpecifiers 


END; 


:  INTEGER; 

:  INTEGER; 

:  GEGDPCurveProperty6; 

:  GEGDPCurveProperty7; 

:  INTEGER; 

:  INTEGER; 

:  array 

[1. . PelArrayLength] 
of  INTEGER) ; 
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€)  6XS  Ada  laaguaga  bindlag  (cefarence  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  GDP ' s  are  In  a  library  package  named  GKS_GDP .  GKS  Ada 
provides  a  data  type  package/  GKS^TYPES  which  provides  types 
declarations . 

The  binding  for  the  "procedure  PEL__ARRAY"  form  (as  defined  in 
paragraph  4 . 1  of  the  GKS  Ada  language  binding)  of  the  GDP  is : 


— (3DP  function  for  a  Pel  Array. 

— Data  type  GDP_DATA_RECORD  is  defined  in  package  GKS_(aDP. 

— GDP^ID  and  other  data  types  are  defined  in  package  6KS_TYPES. 


with  GKS_TYPES; 
use  GKS__TYPES; 
package  GKS_GDP  is 

type  CORNER_POINTS  is  new  WC .POINT_ARRAY  (1..3); 
type  ENCODING_TYPE  is  (packed,  run-length,  T.4,  T.6,  LZW) ; 
type  COLOOR__SPECiriCATION_TYPE  is  (indexed,  direct)  ; 
type  PEL_ARRAY_COLOUR_SPECIFIERS  is  array  (NATURAL  rangeO)  of 
ESCAPE_INTEGER) ; . 
type  PEL_ARRAY_DATA_RECORD  is 
record 


PELS_PER  LINE 
LINES_PER  ARRAY 
ENCODING  “ 

COLOUR  SPECIFICATION 
LOCAL  COLOOR_PRECISION 
PEL_ARRAY_LENGTH 
PEL_ARRAY 
end;  ” 


ESCAPE_INTEGER; 

ESCAPE  INTEGER; 

ENCODING  TYPE; 
COLOUR_SPECIFICATIQN_TYPE ; 
ESCAPE  INTEGER; 
escape"  INTEGER; 

PEL  ARRAY  COLOUR  SPECIFIERS; 


procedure  PEL_ABRAY 
(  CORNER_POINTS 
GDP_IDENTIFIER 
PEL_ARRAY_RECORD 

)  ; 


:in  BEZIER  POINTS; 

:in  GDP_IdT 

:in  PEL  ARRAY  DATA  RECORD; 


— more  GDP  procedures  can  be  inserted  here 


end  GKS  GDP; 
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Proposal  Numbor: 


Oats  of  Prsssntatien:  I  9  Saotsfnbor  1988 


Class  of  Qrsohleal  Itsm:  i  ESCAPE 


me  Escape  1 

[Function  Identifier:  I 

I  Set  Indexed  Colour  R 

nse  I 

OsserlDtIon 


This  oseaps  function  sals  a  valus  (or  ths  indsxod  colour  rasponsa  curva.  This  cun/a  is  usad  to  provide  exact 
photomatric  information  in  terms  of  density  for  Indexed  colour  specifications  contained  in  pel  array  primitives. 
See  attached  sheet  for  additionai  details. 


_  Additional  Comments 


This  escape  is  intended  for  use  in  conjunction  with  the  pel  array  generalized  drawing  primitive,  although  it  could 
be  used  for  rendering  other  primitives  as  well. 


_ _  Justification  (or  Inclusion 


Photometric  information  in  terms  of  density  for  indexed  colour  specifications  contained  in  pel  array  primitives  is 
needed  if  output  devices  are  to  reproduce  input  pel  arrays  precisely.  Many  proprietary  systems  (or 
defining/storing/transferring  raster  image  data  provide  this  capability.  This  is  one  in  a  set  of  escapes  that 
provide  extended  rasler/image  data  capabilities  enabeling  the  family  of  computer  graphics  standards  to  meet  the 
requirements  of  office  document  generation/exchange  and  technical  publications. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  escape  as  defined  in  5.2. 

2)  ISO  8632  (COM)  •  Specifies  a  registered  escape  as  defined  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  registered  escape. 

*At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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Paaeription; 


The  purpose  of  the  Set  Indexed  Colour  Response  escape  function  is 
to  define  a  "curve"  providing  exact  photometric  Interpretation 
Information  In  terms  of  optical  density  for  Indexed  colour  Image 
data  contained  In  pel  array  primitives.  In  particular^  If  the  Index 
values  represent  ranges  of  a  monochrome  value  such  as  gray,  this 
escape  can  be  used  to  provide  more  exact  photometric  Interpretation 
Information  for  gray  scale  Image  data.  The  default  curve  Is  linear 
In  Intensity/reflectance. 

Since  optical  density. Is  specified  In  terms  of  fractional  numbers. 
Real  numbers  are  used  for  these  values.  Optical  densitometers 
typically  measure  densities  within  the  range  of  0.0  to  2.0.  If  the 
Indexed  colour  response  curve  Is  known  for  the  data  In  a  pel  array, 
and  If  the  Indexed  colour  response  of  the  output  device  Is  known, 
then  an  Intelligent  conversion  can  be  made  between  the  Input  data 
and  the  output  device.  For  example,  the  output  can  be  made  to  look 
just  like  the  Input .  In  addition.  If  the  Input  Image  lacks  contrast 
(as  can  be  seen  from  the  response  curve) ,  then  appropriate  contrast 
enhancements  can  be  made. 

The  purpose  of  the  Indexed  colour  response  curve  Is  to  act  as  a 
"lookup"  table  mapping  values  from  0  to  2** (local  colour 
precision)-!  Into  specific  density  values.  The  0th  element  of  the 
Indexed  colour  response  curve  array  Is  used  to  define  the  colour 
response  value  for  all  pels  having  an  Index  value  of  0,  the  1st 
element  of  the  Indexed  colour  response  curve  array  Is  used  to 
define  the  colour  response  value  for  all  pels  having  a  value  of  1, 
and  so  on,  up  to  2** (local  colour  precision)-!.  It  is  permissible 
to  have  a  Indexed  colour  response  curve  even  for  bilevel  (1-blt) 
pel  arrays .  The  Indexed  colour  response  curve  will  have  2  values . 

Implementers  may  wish  to  purphase  a  Kodak  Reflection  Density  Guide, 
catalog  number  146,5947,  available  for  $10  or  so  at  prepress  supply 
houses,  and  use  It  to  determine  reasonable  density  values  for  their 
scanner  or  frame  grabber.  If  this  Is  not  practical  the  default 
curve  that  Is  linear  In  Intensity/reflectance  can  be  used. 
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Ralationahip  to  partieqlar _ afean«lag<ig  ; 


1)  C6M  runctlonal  Spaeification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  local  colour  precision  value  in  this  escape  should  match  that 
used  in  subsequent  Pel  Array  GDPs  when  index  colour  is  used.  A 
functional  description  of  the  Set  Indexed  Colour  Response  escape 
parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

LCP  (local  colour  precision)  (I) 
colour  response  curve  (  (2**LCP)  *  R) 

Items  for  Data  Record: 

Integer  IL 
Integer  IA(1) 

Integer  RL 
Real  RA(1) 

Real  RA(2) 

•  •  • 

Real  RA(2**LCP) 

Integer  SL 

Data  Record  Description: 

The  parameters  define  the  local  colour  precision  and  indexed 
colour  response  curve  for  pel  array  data. 


1 

LCP  (local  colour  precision) 

2**LCP 

colour  response  curve  (0) 
colour  response  curve  (1) 

colour  response  curve  ((2**LCP)-1  ) 
0 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way.  The  entire  data 
record,  containing  the  data  record  items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string”,  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items) , 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3)  GXS  Functional  Spaeifieation  (reference  ISO  7942  6KS 
Functional  Description) 

The  set  dash  escape  Is  applicable  at  GKS  level  Oa.  A  functional 
description  of  Its  parameters  is  given  below: 


Mama  Valnaa 

escape  function  identifier  as  assigned 

input  data  record: 

LCP  (local  colour  precision) 
colour  response  curve 

output  data  record: 
none 


Data  Type 
M 


I 

(2**LCP)*R 


Errors : 


9  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,WSOP,  WSAC,  or  SGOP 


4)  GXS  rORTXAM  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  is  proposed  for  the  "GEpqrs”  form 
(as  defined  in  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  is  to  be  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs (LCP,  CRC) 

Input  Parameters: 

INTEGER  LCP  local  colour  precision 

REAL  CRC(2**LCP)  colour  response  curve 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 

Input  parameters  to  the  Pack  Data  Record  function  (GPREC) : 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Real  RA(1) 
Real  RA(2) 


1 

LCP  (local  colour  precision) 
2**LCP 

colour  response  curve  (0) 
colour  response  curve  (1) 


•  •  • 

Real  RA(2**LCP)  colour  response  curve  ((2**LCP)-1  ) 

Integer  SL  0 


Output  parameters  to  the 
INTEGER  IL 
INTEGER  RL 
INTEGER  SL 


Unpack  Data  Record  function 
0 
0 
0 


(GUREC) : 
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5)  Pascal  language  binding  (reference:  ISO  DIS  8651  6KS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape"  as  defined  In  paragraph  €.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1"  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) : 


GREscapeOataIn  «  RECORD 

CASE  Escapeld  :  GTEscapeOataTag  of 
1:  ( 

LocalColourPreclslon  :  INTEGER; 

ColourResponseCurve  :  array  [1. . (2**LocalColourPreclsion) 

of  REAL); 


END; 


1 


GREscapeDataOut  -  RECORD 

CASE  Escape ID  :  GTEscapeDataTag  of 
1:  ()  ;  (*Null  Record*) 

END; 


6)  GKS  Ada  language  binding  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS_ESCAPE.  GKS 
Ada  provides  a  data  type  package^  GKS_TYPES  which  provides  type 
declarations .  ” 

The  binding  for  the  "procedure  SET_INDEXED__COLOUR_RESPONSE"  form 
(as  defined  in  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of 
the  ESCAPE  Is: 


— Escape  function  to  set  the  Indexed  colour  response  curve  for  a 
— pel  array. 

— Data  types  ESCAPE_ID  and  ESCAPE  FLOAT  are  defined  in  package 
— GKS__ESCAPE .  ” 

—Other  data  types  are  defined  in  package  GKS_TYPES. 

with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  Is 

type  COLOUR__RESPONSE  CURVE  is  array 

(SMALL_NATURAL  range  <>)of  ESCAPE_FLOAT : 
type  INDEXED_COLOUR_RESPONSE_RECORD  is 
record 

LOCAL_COLOUR_PRECISION  :in  INTEGER; 

COLOUR_RESPONSE  :  in  COLOUR_RESPONSE_CURVE 

(0. . (2**LOCAL_COLOUR_PRECISION-l) ) ; 

end  record; 

procedure  SET_INDEXED_COLOUR_RESPONSE 

(ESCAPE_IDENTIFIER  : in  ESCAPE_ID; 

COLOUR_RESPONSE  : in  INDEXED_COLOUR_RESPONSE_RECORD  ) ; 

— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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iDaf  of  Pf8«nf tion;  I  9  Sapteitibf  1988  | 

I  Sponsoring  Authority!  I  ANSI  I 

i  Clisa  of  Graphical  Ham;  I  ESCAPE  I 

1  SpacIMc  Eacapa  I  Function  Idantifiar;  I  Sat  Dtract  Colour  Rasponaa  I 


Daacrtptlon _ 

This  atcapa  (unction  sals  a  valua  for  tha  diract  colour  rasponaa  cunra.  This  cuiva  is  usad  to  provida  axact 
photomatrie  information  in  (arms  of  intansity  for  diract  colour  spacHications  containad  in  pal  array  primitivas. 
Saa  attaehad  shaat  (or  additionaf  datails. 


Additional  Commants 

This  ascapa  is  intandad  for  usa  in  conjunction  with  tha  pal  array  ganaralizad  drawing  primithra.  although  it  could 
ba  used  for  rendering  other  primitivas  as  wall. 


Justification  for  Inclusion 

Photometric  information  in  terms  of  intansity  for  directly  spaciftad  colour  contained  in  pal  array  primitivas  is 
needed  if  output  davicas  are  to  reproduce  input  pal  arrays  precisely.  Many  proprietary  systems  for 
dafining/storing/transfarring/viawing  raster  image  data  provida  this  capability.  This  is  one  in  a  sal  of  escapes 
that  provida  extended  rastar/imaga  data  capabilitias  anabaiing  tha  family  of  computer  graphics  standards  to 
meat  the  requirements  of  olfiea  document  ganaration/axchanga  and  technical  puNications. 


I  Balatlonship  to  Standards  I 


1)  ISO  7942  (GKS)  •  Specifies  a  ragistarad  ascapa  as  defined  hi  5.2. 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  ascapa  as  daflnad  in  5.8.1. 

*3)  ISO  8651  (GKS  Language  Bindings)  •  Specifies  a  ragistarad  ascapa. 

*At  present  at  tha  stage  of  draft  Tha  status  of  this  rslationsNp  is  provisional  until  this  standard  has  been 
approved  by  ISO  council. 
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P^aerlafeion; 


The  purpose  of  the  Set  Direct  Colour  Response  escape  function  is 
to  define  a  "curve"  providing  exact  photometric  Interpretation 
information  in  terms  of  intensity  for  direct  colour  image  data 
contained  in  pel  array  primitives.  Three  colour  response  curves, 
one  each  for  Red,  Green  and  Blue  color  Information  are  defined. 
The  Red  entries  come  first,  followed  by  the  Green  entries, 
followed  by  the  Blue  entries.  The  default  curves  are  linear  in 
Intensity/reflectance.  The  length  of  each  subcurve  is  2** (local 
colour  precision),  using  the  same  local  colour  precision  value  as 
subsequent  pel  array  generalized  drawing  primitives.  Each  entry  is 
a  16  Integer  value.  0  represents  the  minimum  intensity,  and  65535 
represents  the  maximum  intensity.  Black  is  represented  by  (0,0,0), 
and  white  by  (65535,  65535,  65535) .  Therefore,  a  color  response 
curve  entry  for  direct  (RGB)  colour  data  with  a  local  colour 
precision  of  8  bits  would  have  3  *  256  entries,  each  consisting  of 
a  16  bit  integer. 
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feo  parteienlar _ atlBtllgda ; 

.1)  CGM  rimetioiial  Specification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

The  local  colour  precision  value  In  this  escape  should  match  that 
used  In  subsequent  Pel  Array  GDPs  when  Index  colour  Is  used.  A 
functional  description  of  the  Set  Indexed  Colour  Response  escape 
parameters  Is: 

Parameters : 

function  Identifier  (I)  as  assigned  by  the  Registration 

Authority 


data  record  (D) : 

LCP  (local  colour  precision)  (I) 
red  response  curve  (  (2**LCP)  *  I) 
green  response  curve  (  (2**LCP)  *  I) 
blue  response  curve  (  (2**LCP)  *  I) 


Items  for  Data 
Integer 
Integer 
Integer 
Integer 

Record : 

IL 

IA(1) 

IA(2) 

IA(3) 

1  +  3*(2**LCP) 

LCP  (local  colour  precision) 
red  response  curve  (0) 
red  response  curve  (1) 

«  •  • 

Integer 

Integer 

'Integer 

IA(2**LCP+1) 

IA(2**LCP+2) 

IA(2**LCP+3) 

red  response  curve  ((2**LCP)-1  ) 
green  response  curve  (0) 
green  response  curve  (1) 

•  •  • 

Integer 

Integer 

Integer 

IA(2*2**LCP+1) 

IA(2*2**LCP+2) 

IA(2*2**LCP+3) 

green  response  curve  ((2**LCP)-1  ) 
blue  response  curve  (0) 
blue  response  curve  (1) 

«  «  • 

Integer 

Integer 

Integer 

IA(3*2**LCP+1) 

RL 

SL 

blue  response  curve  ((2**LCP)-1  ) 

0 

0 

Data  Record  Description: 

The  parameters  define  the  local  colour  precision  and  indexed 
colour  response  curve  for  pel  array  data. 


2)  CGM  encodings  (reference  ISO  8632  CGM;  Parts  2,3^4) 

All  encodings  will  be  handled  In  the  same  way.  The  entire  data 
record,  containing  the  data  record  Items  in  sequential  order  from 
first  to  last,  will  be  treated  as  a  string.  Ignoring  (for  the 
moment)  the  contents  of  the  "string",  the  entire  data  record  will 
be  encoded  according  to  the  rules  for  string  in  that  encoding. 
Considering  the  string  contents  (that  is,  the  data  record  items), 
the  base  data  types  in  the  data  record  are  encoded  according  to  the 
encoding  rules  for  that  type  in  that  encoding.  For  example,  in  the 
binary  encoding,  a  data  record  that  contains  two  16  bit  integers 
would  be  coded  as  if  it  were  a  string  of  length  4.  Within  the  four 
octets  that  comprise  the  string's  contents,  the  two  16  bit  integers 
would  be  coded  using  the  binary  coding  for  16  bit  binary  integers. 
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3}  6X3  Foaetioas'  Spaeifioatioa  (reference  ISO  7942  GKS 

Functional  Description) 

The  set  dash  escape  Is  applicable  at  GKS  level  Oa.  A  functional 
description  of  Its  parameters  Is  given  below: 


Name  Values  Data  Type 

escape  function  Identifier  as  assigned  N 

Input  data  record: 

LCP  (local  colour  precision) 
red  response  curve 
green  response  curve 
blue  response  curve 

output  data  record: 
none 

Errors : 

8  GKS  not  in  proper  state:  GKS  shall  be  either  in  one  of  the 
states  GKOP,tfSOP,  tfSAC,  or  SGOP 

4)  GKS  rORTBAN  language  binding  (reference  ISO  DIS  8651/1  GKS 
Language  Bindings;  Part  1:  FORTRAN) 

a)  The  following  language  binding  Is  proposed  for  the  "GEpqrs”  form 
(as  defined  In  Paragraph  9.1  of  the  GKS  FORTRAN  language  binding) 
of  the  escape  (pqrs  Is  to  lae  assigned  by  the  Registration  Authority 
to  correspond  to  the  assigned  Register  Identifier) : 

SUBROUTINE  GEpqrs(LCP,  RCRC»  GCRC,  BCRC) 

Input  Parameters : 

INTEGER  LCP  local  colour  precision 

INTEGER  RCRC(2**LCP)  red  response  curve 
INTEGER  GCRC(2**LCP)  green  response  curve 
INTEGER  BCRC(2**LCP)  blue  response  curve 

Output  Parameters: 

NONE 

b)  The  following  parameters  are  proposed  for  use  when  accessing 
this  escape  through  the  GESC  function  of  Paragraph  9.3  of  the  GKS 
FORTRAN  language  binding  standard: 


I 

(2**LCP)*I 
(2**LCP)*I 
(2**LCP) *I 
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Input  paraoMters  to  tha  Pack  Data  Record  function  (GPREC) : 


Items  for  Data 

Integer 

Record : 

IL 

1  +  3*(2**LCP) 

Integer 

IA(1) 

LCP  (local  colour  precision) 

Integer 

IA(2) 

red  response  curve  (0) 

Integer 

IA(3) 

red  response  curve  (1) 

•  •  • 

Integer 

IA(2**LCP+1) 

red  response  curve  ((2**LCP)-1  ) 

Integer 

IA(2**LCP+2) 

green  response  curve  (0) 

Integer 

IA(2**LCP+3) 

green  response  curve  (1) 

•  •  • 

Integer 

IA(2*2**LCP*»-1) 

green  response  curve  ((2**LCP)-1  ) 

Integer 

IA(2*2**LCP+2) 

blue  response  curve  (0) 

Integer 

IA(2*2**LCP+3) 

blue  response  curve  (1) 

•  •  • 

Integer 

IA(3*2**LCP+1) 

blue  response  curve  ((2**LCP)-1  ) 

Integer 

RL 

0 

Integer 

SL 

0 

Output  parameters  to  the  Unpack  Data  Record  function  (GUREC) : 
INTEGER  IL  0 

INTEGER  RL  0 

INTEGER  SL  0 

5)  Paacal  language  binding  (reference:  ISO  DIS  8651  GKS 
Language  Bindings;  Part  2:  Pascal) 

The  following  Pascal  language  binding  Is  proposed  for  the  procedure 
"GEscape**  as  defined  In  paragraph  6.2  of  the  GKS  Pascal  language 
binding  (note  the  case  variant  "1”  will  be  replaced  with  the  actual 
ESCAPE  Identifier  at  registration) t 


GREscapeDataln  •  RECORD 

CASE  Escapeld  :  GTEscapeDataTag  of 
1:  ( 

LocalColourPreclslon  :  INTEGER; 

RedResponseCurve  :  array  (1 . .  (2**LocalColourPreclsion)  ] 

of  INTEGER); 

GreenResponseCurve  :  array  [1 . . (2**LocalColourPreclsion) ] 

of  INTEGER); 

BlueResponseCurve  :  array  [1. .  (2**LocalColourPrecislon) ] 

of  INTEGER); 

END; 

GREscapeDataOut  «  RECORD 

CASE  EscapelD  :  GTEscapeDataTag  of 
1:  0  ;  (*Null  Record*) 

END; 


148 


6)  GKS  Ada  laaguaga  biadlag  (reference  ISO  DIS  8651/3  GKS 
Language  Bindings;  Part3:  Ada) 

Registered  ESCAPE'S  are  in  a  library  package  named  GKS__ESCAPE.  GKS 
Ada  provides  a  data  type  package,  GRS_TYPES  which  provides  type 
declarations . 

The  binding  for  the  "procedure  SET_DIRECT_COLOUR_RESPONSE"  form  (as 
defined  in  Paragraph  4.1  of  the  GKS  Ada  language  binding)  of  the 
ESCAPE  is: 


—Escape  function. to  set  the  indexed  colour  response  curve  for  a 
— pel  array. 

—Data  types  ESCAPE_ID  and  ESCAPE  FLOAT  are  defined  in  package 
— GKS_ESCAPE .  " 

—Other  data  types  are  defined  in  package  GKS_TYPES. 

with  GKS_TYPES; 
use  GKS_TYPES; 
package  GKS_ESCAPE  is 

type  DIRECT_COLOUR_RESPONSE_CORVE  is  array 
(SMALL_NATURAL  range  <>)of  INTEGER: 
type  DIRECT_COLOUR_RESPONSE_RECORD  is 
record 

LOCAL_COLOUR_PRECISION  :in  INTEGER; 

COLOUR_RESPONSE  :in  DIRECT  COLOUR_RESPONSE_CURVE 

(0. . (2**L0CAL_C0L0UR_PRECISI0N-1)  )  ; 

end  record;  ” 

«  ^ 

procedure  SET  DIRECT  COLOUR_RESPONSE 

(ESCAPE  IDENTIFIER  : in  ESCAPE  ID; 

C0L0UR“RESP0NSE  : in  DIRECT"COLOUR_RESPONSE_RECORD  ) ; 

— more  ESCAPE  procedures  can  be  inserted  here 
end  GKS  ESCAPE; 
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This  page  left  intentionally  blank. 
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APPENDIX  1 

RESPONSES  TO  BALLOT  COMMENTS 
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PROPOSAL  36-SET  DASH 


1)  6SS  #5:  Your  comment  Is  not  accepted.  The  dash  pattern 

length  should  be  specified  in  VDC  to  match  the  way  that  the  line 
width  specifier  for  the  Line  Width  C6M  element  is  specified  when 
line-width  specification  mode  is  absolute.  This  gives  a  level  of 
control  similar  to  that  PostScript  gives,  where  both  line  width 
and  dash  pattern  are  specified  in  the  same  coordinate  system 
( "user  coordinates" . ) 

2)  DRI  #25:  Your  comment  is  accepted.  We  have  completely 

changed  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  "string"  using  the  base  types  for  each 
encoding  within  the  string. 

3)  Apollo  #34:  Your  comments  are  accepted.  We  have  completely 
changed  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  "string"  hsing  the  base  types  for  each 
encoding  within  the  string.  Further,  we  agree  with  you  that  all 
the  escapes  in  the  set  should  be  "workstation  independent”,  and 
have  removed  the  workstation  ID  from  all  the  proposals.  Thank 
you  for  your  excellent  and  insightful  comments. 

4)  System  one  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

5)  Henderson  Software  #52:  Your  comments  are  accepted.  where 
the  parameters  of  our  proposed  "direct"  line  attribute 
specifications  overlap  those  of  the  "indexed"  ones  of  the 
"initial  text"  of  CGEM  Addendum  3,  we  have  changed  ours  to  match 
yours.  We  would  like  to  point  out  several  facts,  however: 

a)  the  Line  Type  Definition  in  tile  "CGEM"  is  indexed,  not 
'direct;  our  requirements  dictate  a  direct 
specification ; 

b)  the  Line  Type  Definition  in  the  "CGEM"  is  too  complex 
for  our  purposes; 

c)  the  Line  Type  Definition  in  the  "CGEM"  has  no 
counterpart  to  the  "continuity"  parameter  m  our 
proposal ; 

d)  "CGEM"  text  is  in  a  very  preliminary  state,  with  no 
consensus  reached  even  within  ANSI,  let  alone 
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internationally.  Following  the  1  year  SC24  study 
period  in  this  area,  work  may  start  within  150  that 
could  produce  a  stedsle  set  of  extensions  in  2>3  years. 
Our  registration  proposals  are  based  on  current 
commercial  practice  and  are  urgently  needed  to  meet 
present  needs.  While  we  will  endeavor  to  make  every 
attempt  to  be  compatible  with  early  CGEM  text,  we  can 
neither  take  the  level  of  consensus  represented  by  that 
text  too  seriously  nor  can  we  wait  3-4  years  for  DIS 
"CGEM”  text  to  base  our  proposals  on.  To  put  the  shoe 
on  the  other  foot,  "are  you  willing  to  freeze  your  CGEM 
draft  if  we  agree  to  make  our  proposals  totally 
compatible?**  Even  if  you  are,  you  can*t  because  of  the 
way  in  which  the  consensus  standards  making  process 
works.  Registration  is  a  *'weaker"  mechanism  than 
consensus  standardization.  It  is  designed  to  rapidly 
**register**  (not  standardize)  standards-related  items  of 
use  to  more  than  one  implementation.  We  do  not  expect 
the  CGEM  work  to  be  *'bound**  in  any  way  by  the  items  we 
register.  We  fully  expect  that  3-4  years  of  consensus 
standardization  work  will  result  in  CGM  extensions  that 
are  superior  to,  and  that  will  eventually  replace, 
ours. 

6)  Sun  #12:  Your  comment  is  accepted.  We  have  added  default 

values  to  proposals  36,  37,  and  39. 

• 

7)  HP  #4:  Your  comment  is  accepted.  We  have  changed  the  word 

**reguired'*  to  '*provided  in  the  suggested  location. 


PROPOSAL  37-SET  LINE  CAP 

1)  i^wllo  #34:  Your  comments  are  accepted.  We  have  completely 
changed  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  *’string*'  using  the  base  types  for  each 
encoding  within  the  string.  Further,  we  agree  with  you  that  all 
the  escapes  in  the  set  should  be  *'workstation  independent'*,  and 
have  removed  the  workstation  ID  from  all  the  proposals.  Thank 
you  for  your  excellent  and  Insightful  comments. 

2)  System  One  Software  #53:  Yoxir  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  ** string**  using  the 
base  types  for  each  encoding  within  the  string. 

3)  Henderson  Software  #52:  Your  comments  are  accepted.  We  have 
changed  the  text  of  this  proposal  to  match  that  of  the  Line  Cap 
element  of  the  '*CGEM'*'*  document  (SC24  N52) . 
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4)  Sun  #12:  Your  comment  is  accepted.  We  have  added  default 
values  to  proposals  36,  37,  and  39. 

5)  Nova  Graphics  #13:  In  answer  to  your  comment  (1} ,  the 
PostScript  Specification  has  been  placed  in  the  public  domain, 
and  we  have  informed  Adobe  Systems  of  the  extensions  to  Computer 
Graphics  standards  that  we  are  writing.  In  answer  to  your 
comment  (2) ,  we  have  adopted  the  same  association  of  this 
attribute  to  primitives  as  the  CGEM  has.  There  are  no  compound 
objects  in  our  approved  standards  to  worry  about  applying  them 
to. 


PROPOSAL  38-SET  MITRE  LIMIT 

1)  J^mllo  #34:  Your  comments  are  accepted.  We  have  completely 
changed  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  "string"  using  the  base  types  for  each 
encoding  within  the  string.  Further,  we  agree  with  you  that  all 
the  escapes  in  the  set  should  be  "workstation  independent",  and 
have  removed  the  workstation  ID  front  all  the  proposals.  Thank 
you  for  your  excellent  and  insightful  comments. 

2)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

3)  Henderson  Software  #52:  Your  comments  were  partially 
accepted.  Where  the  parameters  of  our  proposed  attribute 
specifications  overlap  those  of  the  "initial  text"  of  CGEM 
Addendum  3  (;aC24  N52) ,  we  have  changed  ours  to  match  yours.  we 
have  not  adopted  the  Mitre  Limit  definition  from  the  CGEM 
however,  opting  instead  for  a  reformulation  proposed  by  IIP  and 
Nova  Graphics.  We  suggest  that  the  CGEM  do  likewise. 

4)  Nova  Graphics  #13:  Your  comments  are  accepted.  We  have 
changed  the  word  spelling  of  "miter"  to  "mitre"  throughout  the 
proposal.  We  have  modified  the  mitre  limit  definition  as  you 
suggested  to  make  it  more  "continuous."  In  answer  to  your 
comment  (I) ,  the  PostScript  Specification  has  been  placed  in  the 
public  domain,  and  we  have  informed  Adobe  Systems  of  the 
extensions  to  Computer  Graphics  standards  that  we  are  writing. 
In  answer  to  your  comment  (2) ,  we  have  adopted  the  same 
association  of  this  attribute  to  primitives  as  the  CGEM  has. 
There  are  no  compound  objects  in  our  approved  standards  to  worry 
about  applying  them  to. 
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PROPOSAL  39-SET  LIME  JOIN 

1)  #34:  Your  connents  are  accepted.  We  have  completely 
ch2uiged  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  "string”  using  the  base  types  for  each 
encoding  within  the  string.  Further,  we  agree  with  you  that  all 
the  escapes  in  the  set  should  be  "workstation  independent",  and 
have  removed  the  workstation  10  from  all  the  proposals.  Thank 
you  for  your  excellent  and  insightful  comments. 

2)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

3)  Henderson  Software  #52:  Your  comments  are  accepted.  We  have 
changed  the  text  of  this  proposal  to  match  that  of  the  Line  Join 
element  of  the  "CGEM""  document  (SC24  N52) . 

4)  Sun  #12:  Your  comment  is  accepted.  We  have  added  default 
values  to  proposals  36,  37,  and  39. 

5)  Nova  Graphics  #13:  In  answer  to  your  comment  (ir,  the 
PostScript  Specification  has  been  placed  in  the  public  domain, 
and  we  have  informed  Adobe  Systems  of  the  extensions  to  Computer 
Graphics  standards  that  we  are  writing.  In  answer  to  your 
comment  (2) ,  we  have  adopted  the  seune  association  of  this 
attribute  to  primitives  as  the  CGEM  has.  There  are  no  compound 
objects  in  our  approved  standards  to  worry  about  applying  it  to. 


PROPOSAL  40-CaBIC  BEZIER  CURVE 

1)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

2)  Henderson  Software  #52:  We  are  gratified  that  the  CGM  group 
has  chosen  our  publications  on  required  extensions  to  the  CGM  as 
the  basis  for  their  work.  We  note  with  pleasure  that  CGM 
addendum  3  is  based  word-for-word  on  our  proposals  in  most  cases. 
In  so  far  as  possible,  we  will  work  with  the  CGM  group  to  insure 
that  registered  items  and  CGM  extensions  are  as  compatible  as 
possible  given  the  different  time  frames  for  these  two  projects. 

3)  US  Navy  #50:  The  name  has  been  changed  to  Ciibic  Bezier  Curve. 
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4)  Apollo  #34:  Your  comments  are  accepted.  We  have  completely 
changed  the  description  of  the  encoding  of  escape  elements  in  all 
the  proposals.  After  surveying  commercial  practice,  we  have 
settled  on  a  coding  as  a  "string**  using  the  base  types  for  each 
encoding  within  the  string.  Further,  we  agree  with  you  that  all 
the  escapes  in  the  set  should  be  "workstation  Independent",  and 
have  removed  the  workstation  ID  from  all  the  proposals.  A 
description  of  allowable  errors  has  been  added  to  each  escape  and 
GOP.  We  have  moved  the  material  describing  the  general 
fxinctionality  of  each  GDP  and  Escape  to  the  "description" 
section. 

Thank  you  for  your  excellent  and  insightful  comments. 

5)  3M  #44:  We  have  revised  the  proposal  to  incorporate  your 

suggested  replacement  wording. 


PROPOSAL  41-CONIC  ARC 

1)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

2}  Henderson  Software  #52:  We  are  gratified  that  the  CGH  group 
has  chosen  our  pviblications  on  required  extensions  to  the  CGM  as 
the  basis  for  their  work.  We  note  with  pleasure  that  CGM 
addendum  3  is  based  word-for-word  on  our  proposals  in  most  cases. 
In  so  far  as  possible,  we  will  \fork  with  the  C(H1  group  to  insure 
that  registered  items  and  CGM  extensions  are  as  compatible  as 
possible  given  the  different  time  frames  for  these  two  projects. 

3)  3M  #44:  We  have  revised  the  proposal  to  incorporate  your 
suggested  replacement  wording. 

4)  DRl  #25:  Apparently  developers  of  the  CGM  felt  that  is  was 
reasonable  to  require  the  use  of  real  par2UBeters  in  an  integer 
VDC  system.  For  examples,  check  the  binary  encodings  of  both 
Character  Spacing  and  Character  Expansion  Factor,  both  of  which 
are  type  Real  irrespective  of  the  VDC  Type.  We  feel  that  the  use 
of  Real  is  also  justified  in  this  case  for  similar  reasons, 
consequently  we  cannot  accept  your  comment. 

5)  Hewlett-Packard  #4:  We  have  modified  our  proposal  to  be 
compatible  with  CGM  Addendum  3,  consequently  we  cannot  accept 
your  comments  as  that  conflict  with  that  addendum.  The  term 
"counterclockwise"  is  now  defined  in  the  proposal. 
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6)  McDonnell  Douglas  Corporation  #19:  We  have  revised  the 
proposals  as  you  suggested  and  have  extracted  material  from  the 
IGES  specifications,  rather  than  incorporating  that  material  by 
reference.  Although  we  are  concerned  about  compatibility  issues 
when  this  is  done,  it  is  clear  to  us  that  the  graphics  standards 
commvinity  is  not  yet  mature  enough  to  be  eUsle  to  adopt  material 
"not  invented  here”  without  getting  their  hands  into  modifying 
it.  The  changes  required  were  slight,  since  the  CGM  Addendum  3 
material  is  only  slightly  re-worded  from  our  proposals  and  made 
only  insignificant  deletions  to  the  referenced  IGES  material. 

We  recommended  carrying  tile  TPX  and  TFT  pareuneters  for  the  same 
reasons  that  IGES  does,  and  we  certainly  realized  that  the 
receiving  system  can  derive  them  from  other  information.  We  have 
accepted  your  comment  and  have  removed  them. 

7)  Apollo  #34:  We  have  revised  our  proposals  based  on  comments 
by  others  to  be  more  compatible  with  cGM  Addendum  3 .  This 
requires  that  certain  "points"  in  definition  space  be  treated 
like  "VOC  points  for  coding  purposes.  This  also  suggests  that 
we  ignore  the  issue  of  the  start  and  end  points  not  being  on  the 
curve  since  CGM  Addendum  3  ignores  this  problem.  We  did  add  text 
to  require  these  points  to  be  on  the  curve,  and  will  suggest  that 
the  CGM  group  do  likewise. 

We  have  modified  the  descriptions  of  our  proposed  GDPs  to  make 
their  adaption  into  different  standards  easier.  One  flaw  in  the 
registration  process  is  that  a  single  "description"  is  supposed 
to  apply  to  all  standards.  This  is  difficult,  since  coordinates 
are  often  in  WC  in  standards  like  GKS  and  in  VDC  in  the  CGM.  We 
have  tried  to  work  around  this  by  describing  things  in  generic 
terms  and  then  specializing  in  the  "Relationship  to  Standards" 
section. 

We  agree  with  you  that  the  start  and  end  points  in  the  GKS 
binding  do  not  belong  in  "WC"  and  are  not  transfonoed  as  usual 
GDP  "points."  We  have  moved  them  to  the  data  record  as  you 
suggested.  We  have  made  similar  changes  to  the  GKS  FORTRAM 
binding  to  eliminate  the  N,  PXA  and  PYA  values. 

8)  Nova  Graphics  #13:  The  proposed  escape  does  not  violate 
minimality  since  it  is  more  general  that'  the  elliptical  arc 
already  in  tile  CGM.  On  the  issue  of  parameterization,  we  have 
revised  our  parameterization  to  be  consistent  with  CGM  Addendum 
3.  (While  we  are  sympathetic  with  your  observations  on 
parameterization  and  numerical  sensitivities,  we  chose  to  remain 
compatible  with  IGES  usage.  Clearly,  this  is  not  acceptable  to 
most  graphics  folks,  so  we  have  changed.) 
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PROPOSAL  42-SET  COMIC  ARC  TRANSFORMATION  MATRIX 

1)  SyfftCB  One  Software  #53:  Your  comaent  is  accepted.  We  have 
conpletely  ch2mged  the  description  of  the  encoding,  of  escape 
elements  in  all  the  proposals.  After  sxarveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

2)  Hamdermon  Software  #52:  We  are  gratified  that  the  C6M  group 
has  chosen  our  publications  on  required  extensions  to  the  CGM  as 
the  basis  for  their  work.  We  note  with  pleasure  that  CGM 
addendum  3  is  based  word-for-word  on  our  proposals  in  most  cases. 
In  so  far  as  possible,  we  will  work  with  the  CGM  group  to  insure 
that  registered  items  emd  CGM  extensions  are  as  compatible  as 
possible  given  the  different  time  frames  for  these  two  projects. 
We  have  made  several  changes  to  this  particular  proposal  based  on 
letter  ballot  comments.  For  example,  we  converted  to  the  use  of 
a  "homogeneous  coordinates"  formulation  of  the 
transformation/translation  process.  We  suggest  that  you  make 
similar  changes  to  CGM  Addendum  3. 

3)  Pansophic  #24:  Your  comment  is  accepted.  We  removed  the 
offending  part  of  the  functional  specification. 

4)  Hewlett-Packard  #4:  While  we  are  sympathetic  to  y9ur  concerns 
2ibout  the  Introduction  of  a  new  "pipeline"  element  with  the  Conic 
Arc  Transformation  Matrix,  such  a  separate  matrix  element  has 
been  chosen  by  both  IGES  and  CGM  Addendxm  3  (SC24  N52.)  Our 
choice  was  made  to  be  as  compatible  as  possible,  consequently  we 
cannot  accept  your  comment. 

We  have  modified  our  proposal  to  pass  the  coordinates  of  the 
transformation  matrix  in  "homogeneous"  format  as  you  requested. 
We  note  that  this  is  not  the  parameterization  used  in  CGM 
Addendum  3. 

After  reviewing  the  arithmetic  stability  involved  in  the 
computations  against  the  requirements  of  our  constituency,  we 
have  concluded  that  only  real  matrix  values  are  accepteUsly  for 
this  element.  Thus,  we  accept  your  comment  about  the  use  of  real 
values  only  in  this  element. 

5)  DRI  #25:  Developers  of  the  CGM  apparently  felt  that  is  was 
reasonable  to  require  the  use  of  real  parameters  in  an  integer 
VDC  system.  For  examples,  look  at  the  binary  encodings  of  both 
the  Character  Spacing  and  Character  Expansion  Factor  elements, 
both  of  which  are  type  Real  irrespective  of  the  VDC  Type.  We 
feel  that  the  use  of  Real  is  justified  in  this  case  for  similar 
reasons,  consequently  we  cannot  accept  your  comment. 
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6)  i^llo  #34:  We  have  removed  workstation  identifier  as  a 
parameter  in  the  GXS  version  of  this  escape. 

We  agree  with  your  assessment  that  the  parameters  Rij  should  be 
reals  independent  of  the  VDC  type  in  the  CGM  encoding  and  have 
made  this  change. 

We  have  modified  the  descriptions  to  make  the  coordinate  systems 
clearer.  The  transformation  now  maps  a  definition  space  into  VDC 
in  the  case  of  the  CGM,  and  into  WC  in  the  case  of  GKS.  In  the 
GKS  case,  the  current  normalization  tremsformation  would  map  to 
NDC. 

7)  Nova  Graphics  #13:  This  escape  defines  a  "modelling”,  not  a 
"viewing"  transform.  Our  concept  of  doing  it  this  way  has  been 
adopted  by  CGM  Addendum  3.  (We  have  now  modified  our 
parameterizations  to  be  consistent  with  theirs.)  We  don't  see 
that  your  comments  apply  in  this  case. 

8)  McDonnell  Douglas  Corporation  #19:  We  have  revised  the 
proposals  as  you  suggested  and  have  extracted  material  from  the 
IGES  specifications,  rather  than  incorporating  that  material  by 
reference.  Although  we  are  concerned  about  compatibility  issues 
when  this  is  done,  it  is  clear  to  us  that  the  graphics  standards 
commxinity  is  not  yet  mature  enough  to  be  eUale  to  adopt  material 
"not  invented  here"  without  getting  their  hands  into  modifying 
it.  The  chzmges  required  were  slight,  since  the  CGM  Addendum  3 
material  is  only  slightly  re-worded  from  our  proposals  and  made 
only  Insignificant  deletions  to  the  referenced  IGES  material. 


PROPOSAL  43-PARAMETRIC  SPLINE  CURVE 

1)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string”  using  the 
base  types  for  each  encoding  within  the  string. 

2)  Henderson  Software  #52:  We  are  gratified  that  the  CGM  group 
has  chosen  our  publications  on  required  extensions  to  the  CGM  as 
the  basis  for  their  work.  We  note  with  pleasure  that  CGM 
addendum  3  is  based  word-for-word  on  our  proposals  in  most  cases. 
In  so  far  as  possible,  we  will  work  with  the  CGM  group  to  insure 
that  registered  items  and  CGM  extensions  are  as  compatible  as 
possible  given  the  different  time  frames  for  these  two  projects. 

3}  3M  #44:  We  have  revised  the  proposal  to  incorporate  ycur 

suggested  replacement  wording. 

4)  Puk  #26:  The  omission  of  IA(4)  was  a  typographical  error  that 


159 


has  bssn  corrsctsd. 


5)  E&S  #36:  Your  coumsnt  concerns  a  note  in  the  IGES 
specification  regarding  the  availability  of  certain  conversion 
software.  He  merely  repeated  the  IGES  wording.  You  will  have  to 
taJce  your  question  up  with  NBS.  He  have  removed  the  offending 
paragraph  from  our  revised  proposal,  so  your  objection  has  been 
answered. 

6)  Hewlett  Packard  #4:  After  reviewing  the  arithmetic  stability 
involved  in  the  computations  against  the  requirements  of  our 
constituency,  we  have  concluded  that  only  real  values  are 
acceptadsle  for  this  element.  Thus,  we  accept  your  comment  about 
the  use  of  real  ~C  only  in  this  element. 

He  have  removed  VOC  type  integer,  so  this  satisfies  your 
objections  to  various  typographical  errors.  He  wish  to  point  out 
that  these  errors  resulted  when  GSC  Associates  inputs  were 
transcribed  by  others  and  we  were  afforded  no  opport\inity  to 
review  the  work. 

He  have  corrected  the  value  of  RL.  He  have  reversed  the  lines 
"INTEGER  SL"  and 

Thank  you  for  pointing  out  errors  in  the  Rational  B-spline 
language  bindings.  These  bindings  were  done  by  X3H34,  not  by  us 
as  the  proposer.  He  have  attempted  to  correct  them  however,  but 
our  work  should  be  reviewed.  Further,  we  will  refer  the 
Incomplete  bindings  back  to  X3H34  for  completion. 

7)  McOonnell  Douglas  Corporation  #19:  He  have  revised  the 
proposals  as  you  suggested  and  have  extracted  material  from  the 
IGES  specifications,  rather  them  incorporating  that  material  by 
referf^nce.  Although  we  arm  concerned  about  compatibility  issues 
when  this  is  done,  it  is  clear  to  us  that  the  graphics  standards 
community  is  not  yet  mature  enough  to  be  ed)le  to  adopt  material 
"not  invented  here"  without  getting  their  hands  into  modifying 
it.  The  changes  required  were  slight,  since  the  CGM  Addendum  3 
material  is  only  slightly  re~worded  from  our  proposals  and  made 
only  insignificant  deletions  to  the  referenced  IGES  material. 

8)  i^llo  #34:  That  you  for  pointing  out  the  numerous  errors 
that  resulted  when  our  material  was  transcribed  without  our 
knowledge.  He  have  corrected  those  that  were  typographical. 

He  have  removed  the  "I"'  values  from  the  point  lists  as  you 
requested. 

He  have  dropped  N0RJ4  from  the  specification 

He  have  modified  the  primitives  to  use  only  real  values  as  you 
requested. 
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We  have  corrected  the  nimbers  of  control  points  and  weights. 

9)  Nova  Graphics  #13:  We  have  removed  the  offending  values  from 
the  point  list. 


PROPOSAL  44-RATIONAL  B-SPLZNE  CDKVB 

1)  System  One  Software  #53:  Your  comment  is  accepted.  We  have 
completely  changed  the  description  of  the  encoding  of  escape 
elements  in  all  the  proposals.  After  surveying  commercial 
practice,  we  have  settled  on  a  coding  as  a  "string"  using  the 
base  types  for  each  encoding  within  the  string. 

2)  Henderson  Software  #52:  We  are  gratified  that  the  CGM  group 
has  chosen  our  publications  on  required  extensions  to  the  CGM  as 
the  basis  for  their  work.  We  note  with  pleasure  that  CGM 
addendum  3  is  based  word-for-word  on  our  proposals  in  most  cases. 
In  so  far  as  possible,  we  will  work  with  the  CGM  group  to  insure 
that  registered  items  and  CGM  extensions  are  as  compatible  as 
possible  given  the  different  time  frames  for  these  two  projects. 

3)  3M  #44:  We  have  revised  the  proposal  to  incorporate  your 
suggested  replacement  wording. 

4)  McDonnell  Douglas  Corporation  #19:  We  have  revised  the 
proposals  as  you  suggested  and  have  extracted  material  from  the 
IGES  specifications,  rather  than  incorporating  that  material  by 
reference.  Although  we  are  concerned  eUdout  compatibility  issues 
when  this  is  done,  it  is  clear  to  us  that  the  graphics  standards 
community  is  not  yet  mature  enough  to  be  able  to  adopt  material 
"not  invented  here"  without  getting  their  hands  into  modifying 
it.  The  changes  required  were  slight,  since  the  CGM  Addendum  3 
material  is  only  slightly  re-worded  from  our  proposals  and  made 
only  insignificant  deletions  to  the  referenced  IGES  material. 
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